Системные требования

Системные требования- детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО.

Функциональные требования

Описание работы:

В части системного администрирования приложение должно:

1) проверять разрешение на работу с приложением у пользователя при входе в систему.

2) регистрировать нового, уникального пользователя.

3) восстанавливать пароль, при его утрате.

Разработанное приложение реализует следующие методы протокола HTTP:

1) GET -метод GET предполагает извлечение любой информации (в форме объекта), заданной Request-URI.

2) HEAD - метод HEAD идентичен GET за исключением того, что сервер не должен присылать тело сообщения. Метаинформация, содержащаяся в заголовках отклика на запрос HEAD должна быть идентичной информации посланной в отклик на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, указанном в запросе, без передачи тела самого объекта.

3) PUT- метод PUT требует, чтобы вложенный объект был запомнен с использованием Request-URI. Если Request-URI относится к уже существующему ресурсу, то вложенный объект следует рассматривать как модифицированную версию объекта на исходном сервере. Если Request-URI не указывает на существующий ресурс и запрашивающий агент пользователя может определить этот URI как новый ресурс, исходный сервер может создать ресурс с этим URI.

4) DELETE- метод DELETE требует, чтобы исходный сервер уничтожил ресурс, идентифицируемый Request-URI. Этот метод на исходном сервере может быть отвергнут вмешательством человека (или каким-то иным путем). Клиент не может гарантировать, что операция была выполнена, даже если возвращенный статусный код указывает, что операция завершилась успешно.

5)OPTIONS- метод OPTIONS представляет собой запрос информации о коммуникационных опциях, доступных в цепочке запрос/отклик, идентифицированной Request-URI. Этот метод позволяет клиенту определить опции и/или требования, связанные с ресурсами, или возможности сервера, не прибегая к операциям по извлечению и пересылке каких-либо файлов.

Нефункциональные требования

Описание форматов запросов, посылаемых для каждого из методов:

Сообщение-запрос от клиента к серверу включает в себя, в пределах первой строки сообщения, метод, который должен быть использован для ресурса, идентификатор ресурса и код версии используемого протокола.

Request = Request-Line*( generalheader | requestheader | entityheader )CRLF [ messagebody ]

Строка запроса:

Строка запроса начинается с лексемы метода, за которой следует Request-URI, версия протокола, завершается строка последовательностью CRLF. Элементы разделяются символами SP. Символы CR или LF запрещены кроме завершающей последовательности CRLF.

Request Line = Method SP Request-URI SP HTTP-Version CRLF

Лексема Method указывает на метод, который должен быть применен к ресурсу, обозначенному Request-URI. При записи метода использование строчных или прописных букв не безразлично.

Список методов допустимых для ресурса может быть специфицирован полем заголовка Allow. Возвращаемый код отклика всегда оповещает клиента, допустим ли метод для ресурса. Серверам рекомендуется возвращать статусный код 405 (Метод не допустим), если метод известен серверу, но не приемлем для запрашиваемого ресурса и 501 (Не применим), если метод не узнан или не приемлем для сервера.

URI запроса является универсальным идентификатором ресурса и идентифицирует ресурс, который запрашивается.

Request-URI = "*" | absoluteURI | abs_path

Три опции для Request-URI зависят от природы запроса. Звездочка "*" означает, что запрос приложим не к заданному ресурсу, но к самому серверу, и допустим только, когда используемый метод не обязательно приложим к ресурсу.

Форма абсолютного URI необходима, когда запрос адресован к прокси-серверу. Прокси-серверу посылается запрос переадресации с целью получения отклика.

Для того чтобы разрешить передачу абсолютных URI в запросах будущих версий HTTP, все серверы HTTP/1.1 должны уметь работать с запросами абсолютных форм URI.

Наиболее общей формой Request-URI является та, которая используется для идентификации ресурса на исходном сервере или внешнем порту сети. В этом случае абсолютный проход к URI долженбыть занесен в abs_path как Request-URI, а сетевой адрес URI (net_loc)долженбыть занесен в поле заголовка Host. Абсолютный проход не может быть пустым; если его нет в исходном URI, ондолженбыть задан в виде "/" (корневой каталог сервера).

Поля заголовка запроса:

Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Описание заголовков, используемых при формировании запросов к серверу для всех реализованных методов:

Поле Accept:

Поле заголовка запроса Accept может использоваться для спецификации определенных типов среды, которые приемлемы для данного ресурса. Заголовки Accept могут использоваться для индикации того, что запрос ограничен в рамках определенного набора типов, как в случае запросов отображения в текущей строке.

Accept = "Accept" ":" #( media-range [ accept-params ] )

media-range = ( "*/*" | ( type "/" "*") | ( type "/" subtype ) ) *( ";" parameter )

accept-params = ";" "q" "=" qvalue *( accept-extension ) accept-extension = ";" token [ "=" ( token | quoted-string ) ]

Символ звездочка "*" используется для того, чтобы группировать типы среды в группы с "*/*", указывающим на все типы, и "type/*", указывающим на все субтипы данного типа. Группа сред может включать в себя параметры типа среды, которые применимы. За каждой группой сред можетследовать один или более параметров приема (accept-params), начинающихся с "q" параметра для указания фактора относительного качества. Первый "q" параметр (если таковой имеется) отделяет параметры группы сред от параметров приема. Факторы качества позволяют пользователю или агенту пользователя указать относительную степень предпочтения для данной группы сред, используя шкалу значений q от 0 до 1. Значение по умолчанию соответствует q=1.

Метод Get: «Accept: */*; q=0.9, text/html»

Поле Accept-Encoding:

Поле заголовка запроса Accept-Encoding сходно с полем Accept, но регламентирует кодировку содержимого, которая приемлема в отклике.

Accept-Encoding = "Accept-Encoding" ":" #( content-coding )

Если заголовок Accept-Encoding в запросе отсутствует, сервер можетпредполагать, что клиент воспримет любую кодировку информации. Если заголовок Accept-Encoding присутствует и, если сервер не может послать отклик, приемлемый согласно этому заголовку, тогда серверу следует послать сообщение об ошибке со статусным кодом 406 (Not Acceptable). Пустое поле Accept-Encoding указывает на то, что не приемлемо никакое кодирование.

Метод Get: «Accept-Encoding:»

Метод Put: «Accept-Encoding:»

Поле Accept-Charset:

Поле заголовка запроса Accept-Charset может быть использовано для указания того, какой символьный набор приемлем для отклика.

Accept-Charset = "Accept-Charset" ":"1#( charset [ ";" "q" "=" qvalue ] )

Каждому символьному набору может быть поставлено в соответствие значение качества, которое характеризует степень предпочтения пользователя для данного набора. Значение по умолчанию q=1. Если заголовок Accept-Charset отсутствует, по умолчанию это означает, что приемлем любой символьный набор. Если заголовок Accept-Charset присутствует, и, если сервер не может послать отклик, который приемлем с точки зрения заголовка Accept-Charset, тогда он должен послать сообщение об ошибке со статусным кодом 406 (not acceptable), хотя допускается посылка и отклика "unacceptable".

Метод Put: «Accept-Charset: ISO-8859-1»

Метод Get: «Accept-Charset: windows-1251»

Поле Allow:

Поле заголовка объекта Allow перечисляет набор методов, поддерживаемых ресурсом, идентифицированным Request-URI. Целью этого поля является точное информирование получателя о рабочих методах данного ресурса. Поле заголовка Allow должнобыть представлено в отклике 405 (Method Not Allowed).

Allow = "Allow" ":" 1#method

Поле заголовка Allow можетбыть прислано запросом PUT, чтобы рекомендовать методы, которые будут поддерживаться новым или модифицированным ресурсом. Серверу не обязательно поддерживает эти методы, но емуследуетвключить заголовок Allow в отклик, чтобы сообщить действительно поддерживаемые методы.

Метод Put: «Allow: GET, HEAD, PUT, DELETE»

Поле Connection:

Поле общего заголовка Connection позволяет отправителю специфицировать опции, которые желательны для конкретного соединения. Заголовок Connection имеет следующую грамматику:

Connection-header = "Connection" ":" 1#(connection-token) connection-token = token

HTTP/1.1 определяет опцию "close" (закрыть) для отправителя, чтобы сигнализировать о том, что соединение будет закрыто после завершения передачи отклика.

Метод PUT: «Connection: close»

Метод GET: «Connection: close»

Метод HEAD: «Connection: close»

Метод OPTIONS: «Connection: close»

Метод DELETE: «Connection: close»

Поле Host:

Поле заголовка запроса Host специфицирует ЭВМ в Интернет и номер порта запрашиваемого ресурса в виде, полученном из исходного URL, который выдал пользователь или который получен из указанного ресурса.

Host = "Host" ":" host [ ":" port ] ;

Имя "ЭВМ" без последующего номера порта предполагает значение порта по умолчанию для заданного вида сервиса (напр., "80" для HTTP URL).

Для всех методов поле HOSTизвлекается из указанного пользователемURI.

Поле Content-Length:

Содержимое поля заголовка объекта Content-Length указывает длину тела сообщения в октетах (десятичное число), посылаемое получателю, или в случае метода HEAD, размер тела объекта, который мог бы быть послан при запросе GET.

Content-Length = "Content-Length" ":" 1*DIGIT

Приложениям следуетиспользовать это поле для указания размера сообщения, которое должно быть послано вне зависимости от типа среды.

Метод PUT: «Content-Length:_РАЗМЕР_РЕСУРСА_»

Метод GET: «Content-Length:_РАЗМЕР_РЕСУРСА_»

Тело сообщения:

Тело сообщения HTTP (если имеется) используется для переноса тела объекта, сопряженного с запросом или откликом.

Присутствие тела сообщения в запросе отмечается с помощью включения полей заголовка Content-Length или Transfer-Encoding в заголовки сообщений-запросов. Тело сообщения может быть включено в запрос, только когда метод запроса допускает наличие тела объекта.

Для сообщений-откликов включение в них тела сообщения зависит от метода запроса и статусного кода отклика. Все отклики в случае метода запроса HEAD не должнывключать тела сообщения, даже если присутствуют поля заголовка объекта, позволяющие предположить его присутствие. Все отклики 1xx (информационные), 204 (никакого содержимого) и 304 (не модифицировано)не должнывключать тела сообщения. Все другие отклики включают в себя тело сообщения, хотя оно может иметь и нулевую длину.

Отклик сервера:

После получения и интерпретации сообщения-запроса, сервер реагирует, посылая HTTP сообщение отклик.

Response = Status-Line*( general-header | response-header | entity-header ) CRLF [ message-body ]

Статусная строка:

Первая строка сообщения-отклика является статусной строкой, состоящей из кода версии протокола, за которым следует числовой статусный код и его текстовое представление, все элементы разделяются символами SP (пробел). Никакие CR или LF не допустимы, за исключением завершающей последовательности CRLF.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF