РД 45.134-2000, часть 8
Не все функции, содержащиеся в данном приложении, обязательны для ТС службы доступа к информационным ресурсам по протоколу HTTP , но если они выполняются , то их реализация должна соответствовать настоящему приложению.
2. Функциональные требования к серверу HTTP
2.1. Соединения
2.1.1. Протокол нижнего уровня
Сообщения HTTP должны передаваться с использованием виртуального соединения TCP.
2.1.2. Установление соединения и закрытие соединения
При обмене сообщениями HTTP соединение должно инициироваться стороной клиента. Е сли сервер поддерживает стойкие соединения (см. п. 5.7.), то перед закрытием соединения он должен в сообщение ответа включить поле Connection с меткой close.
Если сервер поддерживает стойкие соединения, то при получении запроса с полем Connection со значением close, он должен ответить на данный запрос и закрыть соединение.
2.1.3. Если сервер поддерживает стойкие соединения, он должен обеспечивать функцию перекачки сообщений клиента в соответствии с п. 5.7.1.1.2.
3. Перечень и структура сообщений протокола HTTP
3.1. Требования к элементам сообщений
3.1.1. В сообщении HTTP должен использоваться формат адреса URI в соответствии с п. 5.2.2.
3.1.2. В сообщении HTTP должен использоваться один из форматов представления даты, приведенных в п. 5.2.3.1.
3.1.3. Промежутки времени в полях сообщения HTTP должны указываться в секундах в виде десятичного числа.
3.2. Типы информации
3.2.1. Процедура согласования содержимого
3.2.1.1. Если сервер поддерживает управляемую сервером процедуру согласования содержимого, он должен использовать поле Vary для указания пределов варьирования представления ресурса. При осуществлении выбора представления сервер должен использовать информацию из полей Accept, Accept-Charset, Accept-Encoding, Accept-Language, Accept-Ranges в соответствии с п. 5.12.1., 5.12.2., 5.12.3., 5.12.4., 5.12.5 .
3.2.1.2. Если сервер поддерживает управляемую клиентом процедуру согласования содержимого, он должен включить перечень возможных представлений ресурса в поле Alternates.
3.2.2. Если сервер отправляет ответ с типом информации, отличным от application/octet-stream , он должен указать данный тип в поле Content-Type. Обозначение типа должно соответствовать RFC 2048 [15].
3.2.3. Если к телу сообщения применяется преобразование, тип преобразования должен быть указан в поле Transfer-Encoding в соответствии с п. 5.12.40.
3 .3. Запросы
3.3.1.
Структура запросов протокола HTTP должна
соответствовать
п. 5
.3.
3.3.2. В сервере должна быть реализована обработка запросов методами GET, HEAD.
3.3.2.1. Если в сервере реализована обработка условных запросов методами GET, HEAD , то для задания условия должны использоваться поля заголовка запроса:
If-Modified-Since;
If-Match;
If-None-Match;
If-Range;
If-Unmodified-Since.
При этом содержание полей должно обрабатываться согласно п. 5.12.24, 5.12.25, 5.12.26, 5.12.27, 5.12.28.
3.3.2.2. Если в сервере реализована обработка запросов диапазонов методом GET , то для задания диапазона должно использоваться поле Range. Содержимое поля Range должно интерпретироваться в соответствии с п. 5.12.36.
3.3.3. Для предоставления клиенту возможности запрашивать информацию о параметрах соединения с запрашиваемым URI должен использоваться метод OPTIONS ( раздел 5.8.2).
3.3.4. Для предоставления клиенту возможности передачи на ресурс с указанным URI дополнительной информации в виде сущности должен использоваться метод POST (п. 5.8.5).
3.3.5. Для предоставления клиенту возможности сохранения на сервере сущности под указанным URI должен использоваться метод PUT (п. 5.8.6). Если в результате запроса клиента сервер создал новый ресурс, он должен выдать ответ 201. В случае невозможности сохранить сущность под указанным URI сервер должен выдать ответ 301.
3.3.6. Для предоставления клиенту возможности удаления ресурса с указанным URI должен использоваться метод DELETE (п. 5.8.7).
3.3.7. Метод TRACE используется для организации удаленного шлейфа (п. 5.8.8). Конечному получателю запроса следует направить полученное сообщение обратно клиенту в качестве тела сущности. При этом клиент должен выдать сообщение 200. Конечный получатель - это либо первоначальный сервер, либо первый прокси или шлюз для получения значения 0 в ответ. Запрос TRACE не должен включать сущность.
3.4. Ответы
3.4.1. Структура ответов сервера должна соответствовать п. 5.5.
3.4.2. Сервер должен поддерживать ответы с кодами статуса, приведенные в табл. 1.
Таблица 1
Ответы с кодами статуса.
-
Код
Описание
100
Продолжить
101
Коммутируемые протоколы
200
OK
201
Создан
202
Принят
203
Ненадежная информация
204
Нет содержимого
205
Переустановить содержимое
206
Частичное содержимое
300
Много выборов
301
Перемещен на постоянный срок
302
Временно перемещен
303
См. другие
304
Не изменен
305
Используй прокси
400
Плохой запрос
401
Неавторизован
402
Требуется оплата
403
Запрещено
404
Не найдено
405
Метод не разрешен
406
Неприменим
407
Требуется идентификация на прокси
408
Тайм-аут запроса
409
Конфликт
410
Ушел
411
Требуется длина
412
Ошибка предварительной обработки
413
Сущность запроса слишком велика
414
URI запроса слишком велико
415
Тип информации не поддерживается
500
Внутренняя ошибка сервера
501
Не реализовано
502
Плохой шлюз
503
Служба недоступна
504
Тайм-аут шлюза
505
Версия HTTP не поддерживается
3.4.3. При генерации ответа сервер должен в поле Etag устанавливать значение, являющееся уникальным среди всех сущностей данного ресурса.
3.4.4. В ответе сервера обязательно должно присутствовать поле Age , значение которого должно вычисляться согласно п. 5.12.6.
3.4.5. В ответе сервера обязательно должно присутствовать поле Date , содержащее дату и время генерации сообщения сервером.
3.5. Взаимодействие клиента и сервера
3.5.1. Сервер не должен выдавать ответ 100 клиенту с версией HTTP ниже 1.1.
4. Требования к реализации сервера HTTP
4.1. Требования к функциям кэша
4.1.1. Если в сервере реализованы функции кэша, они должны соответствовать п. 5.11.
4.1 .2. Ответы на запрос с методом OPTIONS не должны кэшироваться.
4 .1 .3. Если кэш выдает устаревший ответ, в него должно быть включено предупреждение 10 (см. п. 5.12.45, табл. 3).
4.1 .4. Если кэш не может провести проверку актуальности ответа, в данный ответ должно быть включено предупреждение 11 (см. п. 5.12.45, табл. 3).
4 .1 .5. Если кэш применяет преобразование содержимого тела сообщения, изменяющее его кодировку или тип информации, он должен включить в сообщение предупреждение 14 (см. п. 5.12.45, табл. 3).
4.1 .6. Кэш должен обрабатывать ответы как устаревшие, если они имеют значение поля Expires более позднее, чем текущая дата или, если формат поля Expires не соответствует формату даты по п. 3.1.2. настоящих Технических требований.
4.2. Требования к функциям сервера прокси
4.2.1. Если в сервере реализованы функции сервера прокси, они должны соответствовать п. 5.11.
4.2.2. Сервер прокси не должен устанавливать стойкие соединения с клиентами версии HTTP/1.0. и ниже.
4.2.3. Если через прокси проходит ответ на запрос с методом OPTIONS, прокси должен исправить содержимое полей ответа, а также добавить или удалить поля ответа в соответствии с поддерживаемыми им возможностями.
4.2.4. Если сервер прокси не выполняет функции межсетевого экрана, он должен добавлять в поле Via проходящих через него сообщений свой идентификатор в соответствии с п. 5.12.44. Если сервер прокси выполняет выполняет функции межсетевого экрана, то он должен иметь сертификат Гостехкомиссии России.
4.2.5. Если в прокси реализована процедура идентификации клиента, она должна выполняться с использованием полей заголовка Proxy-Authenticate и Proxy-Authorization в соответствии с п. 5.12.33. и 5 .12.34.
4.2.6. Прокси должен добавлять в сообщение запроса поле Host , если данное поле отсутствует в сообщении.
4.2.7. Прокси, получивший сообщение с методом TRACE и полем Max-Forwards=0, не должен направлять данное сообщение, а должен выдать ответ 200 с данным сообщением, включенным в сущность ответа.
4.3. Идентификация доступа
4.3.1. Для начала процедуры идентификации должен использоваться ответ 401 с полем WWW-Authenticate . В процедуре идентификации должно использоваться содержимое поля запроса Authorization. Если сервер не принимает сообщение клиента с полем Authorization , он снова должен выдать ответ 401.
4.3.2. Если сервер поддерживает первичную схему идентификации доступа, ее реализация должна соответствовать п. 5.9.1.
4.4. Согласование протокола
Если сервер поддерживает процедуру согласования протокола, данная процедура должна быть реализована в соответствии с п. 5.12.41.
5. Описание протокола HTTP
5.1. Базовые определения
Спецификация синтаксиса запросов и ответов HTTP приводится в расширенной форме Наура-Бекуса соответствующей RFC-822 [2] .
Базовые определения:
OCTET :: = <8 бит любых данных>
CHAR :: = <любой символ US-ASCII (октеты от 0 до 127)>
UPALPHA :: = <любая прописная буква US-ASCII "A".."Z">
LOALPHA :: = <любая строчная буква US-ASCII "a".."z">
ALPHA :: = UPALPHA | LOALPHA
DIGIT :: = <любая цифра US-ASCII "0".."9">
CTL :: = <любой управляющий символ US-ASCII
(октеты от 0 до 31) и DEL (127)>
CR :: = <US-ASCII CR, возврат каретки (13)>
LF :: = <US-ASCII LF, пропуск линии (10)>
SP :: = <US-ASCII SP, пробел (32)>
HT :: = <US-ASCII HT, горизонтальная табуляция (9)>
<"> :: = <US-ASCII двойные кавычки (34)>
CRLF :: = CR LF
Заголовок HTTP может быть разбит на несколько строк. 2-я и далее строка заголовка должны начинаться с пробела или табуляции.
LWS :: = [CRLF] 1*( SP | HT )
Слова *TEXT могут содержать символы набора, отличного от ISO 8859-1[16] только в случае, если они закодированы в соответствии с RFC 2047[17] .
TEXT :: = <любой OCTET, кроме октетов CTL, но включая LWS>
HEX :: = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
token :: = 1*<any CHAR except CTLs or tspecials>
tspecials :: = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
Если в значении поля заголовка содержатся специальные символы, эти специальные символы должны содержаться в строке в кавычках.
comment :: = "(" *( ctext | comment ) ")"
ctext :: = <любой TEXT кроме "(" и ")">
Строка текста, заключенная в двойные кавычки ("строка в кавычках"), обрабатывается как единое слово.
quoted-string :: = ( <"> *(qdtext) <"> )
qdtext :: = <any TEXT except <">>
Конструкция квотирования "\<символ>" может использоваться только внутри "строки в кавычках" и комментария.
quoted-pair :: = "\" CHAR
5.2. Элементы протокола
5.2.1. Версия HTTP
Версия содержится в поле HTTP-Version в первой строке сообщения.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Номер DIGIT не должен начинаться с нулей.
Прокси и шлюзы никогда не должны посылать сообщения с номером версии большим, чем номер их собственной версии. Если прокси (шлюз) получает ответ с номером версии большим, чем номер версии этого прокси (шлюза), он должен либо изменить сообщение так, чтобы номер версии был понижен, либо ответить сообщением об ошибке, либо работать как тоннель. Если версия запроса, направленного к прокси, меньше версии прокси, то он может перенаправить запрос, повысив версию, но в ответе на данный запрос он должен выдать, используя ту же версию, что и первичный запрос.
5.2.2. Универсальный идентификатор ресурса (URI)
5.2.2.1. Синтаксис
URI может быть представлен в абсолютной форме или относительной к некоторой известной базовой URI форме. Абсолютный URI всегда начинается с имени схемы, за которым следует символ двоеточие.
URI :: = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI :: = scheme ":" *( uchar | reserved )
relativeURI :: = net_path | abs_path | rel_path
net_path :: = "//" net_loc [ abs_path ]
abs_path :: = "/" rel_path
rel_path :: = [ path ] [ ";" params ] [ "?" query ]
path :: = fsegment *( "/" segment )
fsegment :: = 1*pchar
segment :: = *pchar
params :: = param *( ";" param )
param :: = *( pchar | "/" )
scheme :: = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc :: = *( pchar | ";" | "?" )
query :: = *( uchar | reserved )
fragment :: = *( uchar | reserved )
pchar :: = uchar | ":" | "@" | "&" | "=" | "+"
uchar :: = unreserved | escape
unreserved :: = ALPHA | DIGIT | safe | extra | national
escape :: = "%" HEX HEX
reserved :: = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra :: = "!" | "*" | "'" | "(" | ")" | ","
safe :: = "$" | "-" | "_" | "."
unsafe :: = CTL | SP | <"> | "#" | "%" | "<" | ">"
national :: = <любой OCTET кроме ALPHA, DIGIT,
reserved, extra, safe, и unsafe>
Если длина URI превышает максимальную длину, обрабатываемую сервером, сервер должен выдать ответ статуса 414.
5.2.2.2. HTTP URL
URL - универсальный указатель расположения ресурса. URL - тип URI, со схемой http.
http_URL :: = "http:" "//" host [ ":" port ] [ abs_path ]
host :: = <Разрешенное имя домена Internet или адрес IP
в форме десятичных чисел, разделенных точками,
в соответствии с п. 2.1. RFC 1123 [18] )
port :: = *DIGIT
Если port не указан, предполагается порт по умолчанию 80. Если в запросе не указан abs_path, вместо него должен присутствовать "/".
5.2.2.3. При сравнении двух URI с целью выяснения идентичности, клиент должен проводить пооктетное сравнение с учетом регистра всех символов URI. При этом:
- если порт не указан, он считается эквивалентным порту по умолчанию;
- при сравнении имен узлов регистр символов не должен учитываться;
- при сравнении схем регистр не должен учитываться;
- пустой абсолютный путь abs_path эквивалентен значению "/" abs_path.
Символы, не входящие в группы "reserved" и "unsafe" эквивалентны их коду, представленному как ""%" HEX HEX".
5.2.3. Формат даты и времени
5.2.3.1. Полная дата
Существует три допустимых формы представления даты/времени:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822 [2] , с учетом изменений,
; внесенных RFC 1123 [18]
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 1036 [19]
Sun Nov 6 08:49:37 1994 ; формат ANSI C asctime()
Время и дата, указанные в метках даты/времени, должны соответствовать Среднему Гринвичскому времени
HTTP-date :: = rfc1123-date | rfc850-date | asctime-date
; rfc850 - rfc850[20]
rfc1123-date :: = wkday "," SP date1 SP time SP "GMT"
rfc850-date :: = weekday "," SP date2 SP time SP "GMT"
asctime-date :: = wkday SP date3 SP time SP 4DIGIT
date1 :: = 2DIGIT SP month SP 4DIGIT
; день месяц год (Например, 02 Jun 1982)
date2 :: = 2DIGIT "-" month "-" 2DIGIT
; день-месяц-год (Например, 02-Jun-82)
date3 :: = month SP ( 2DIGIT | ( SP 1DIGIT ))
; месяц день (Например, Jun 2)
time :: = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday :: = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday :: = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month :: = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
5.2.3.2. Период в секундах
Некоторые поля заголовка HTTP позволяют указывать значения времени в виде целого числа секунд в десятичной форме, прошедших с момента получения сообщения.
delta-seconds :: = 1*DIGIT
5.2.4. Наборы символов
Термин "набор символов" в протоколе HTTP аналогичен такому же термину, определенному в протоколе MIME.
Набор символов указывает на метод преобразования последовательности октетов в последовательность символов.
charset :: = token
где значение token должно соответствовать RFC 1700 [9] .
5.2.5. Кодирование содержимого
Значения способа кодирования содержимого указывают на преобразование кодировки (например, сжатие), которое применялось, либо может быть применено к сущности.
content-coding :: = token
Определены следующие значения token: gzip (GNU zip согласно RFC 1952 [21] ) и compress.
5.2.6. Кодирование при передаче
Значения кодирования при передаче указывают на преобразование кодировки, которое применялось, либо может быть применено к телу сущности с целью обеспечения "безопасной транспортировки" по сети. Кодирование при передаче является свойством сообщения, а не сущности.
transfer-coding :: = "chunked" | transfer-extension
transfer-extension :: = token
Порционное кодирование (chunked encoding) изменяет тело сообщения таким образом, что оно передается как последовательность порций. Каждая порция имеет свой индикатор размера, за которым следует необязательный раздел, содержащий поля заголовка сущности. Таким образом кодирование при передаче позволяет передавать сообщения с динамически генерируемым содержимым.
Chunked-Body :: = *chunk
"0" CRLF
footer
CRLF
chunk :: = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
hex-no-zero :: = <HEX excluding "0">
chunk-size :: = hex-no-zero *HEX
chunk-ext :: = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name :: = token
chunk-ext-val :: = token | quoted-string
chunk-data :: = chunk-size(OCTET)
footer :: = *entity-header
5.2.7. Типы информации
Для обеспечения открытого определения и согласования типа информации используются поля заголовка Content-Type и Accept.
media-type :: = type "/" subtype *( ";" parameter )
type :: = token
subtype :: = token
parameter :: = attribute "=" value
attribute :: = token
value :: = token | quoted-string
Между элементами type и subtype, а также между parameter и value не должны использоваться символы LWS в качестве разделителя.
Значения media-type должны соответствовать RFC 2048 [15] .
5.2.7.1. Канонические представления информации
Для каждого типа информации зарегистрирована каноническая форма представления. При пересылке в теле сообщения HTTP- информация должна быть представлена в канонической форме.
5.2.7.1.1. Тип text.
В качестве разделителя линии в теле сообщения при типе media-type text могут использоваться отдельные символы CR, LF и пара символов CRLF.
Если не указан набор символов, по умолчанию должен использоваться ISO-8859-1 [16] .
5.2.7.2. Если сообщение содержит несколько тел с различными типами информации, все части сообщения должны иметь формат MIME. В отличие от MIME эпилог (epilogue) не должен передаваться.
5.2.8. Метки продуктов
Метки продуктов позволяют взаимодействующим по сети приложениям определить название и версию программного обеспечения, используемую на другой стороне.
product :: = token ["/" product-version]
product-version :: = token
Например:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
5.2.9. Параметр качества содержимого
Процедура согласования содержимого использует короткие числа с плавающей запятой для указания относительной важности (веса) различных параметров согласования. Веса приведены к нормализованной форме в диапазоне от 0 до 1, где 0 - минимальный вес, а 1 - максимальный. Вес не должен содержать более 3-х цифр после десятичной точки.
qvalue :: = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
5.2.10. Теги языка
Теги языка указывают на естественный язык, используемый для передачи информации между людьми. Синтаксис и допустимое содержание тега языка должны соответствовать RFC 1766 [22] .
language-tag :: = primary-tag *( "-" subtag )
primary-tag :: = 1*8ALPHA
subtag :: = 1*8ALPHA
Первый двухсимвольный тег primary-tag - это аббревиатура языка в соответствии с ISO 639 [23] , а первый двухбуквенный subtag - это код страны по ISO 3166 [24] .
5.2.11. Теги сущности
Теги сущности используются для сравнения двух или более сущностей, поступивших от одного запрашиваемого ресурса.
entity-tag :: = [ weak ] opaque-tag
weak :: = "W/"
opaque-tag :: = quoted-string
Теги сущности должны быть уникальны для всех версий всех сущностей, относящихся к отдельному ресурсу.
5.2.12. Блоки диапазонов
HTTP 1.1 позволяет клиенту затребовать, чтобы только часть (диапазон) сущности ответа была включена в ответ. Сущность может быть разбита на поддиапазоны в соответствии с различными структурными блоками.
range-unit :: = bytes-unit | other-range-unit
bytes-unit :: = "bytes"
other-range-unit :: = token
Единственным обязательным для реализации блоком является bytes-unit.
5.3. Сообщение HTTP
5.3.1. Типы сообщений
Сообщения разделяются на запросы клиента к серверу и ответы сервера клиенту.
HTTP-message :: = Request | Response
Запросы и ответы используют общий формат сообщений RFC 822 [2] для передачи сущностей (полезной нагрузки сообщения). Оба типа сообщения состоят из начальной строки, одной или более строк заголовка, пустой строки, указывающей на конец заголовка, и необязательного тела сообщения.
generic-message :: = start-line
*message-header
CRLF
[ message-body ]
start-line :: = Request-Line | Status-Line
Сервер должен игнорировать пустые строки, поступающие перед Request-Line.
5.3.2. Заголовки сообщений
Поля заголовка HTTP, включая поля общего заголовка, заголовка запроса, заголовка ответа и заголовка сущности, должны соответствовать формату п. 3 .1. RFC 822 [2] . Поля заголовка могут занимать несколько строк, но строки, следующие за первой, должны начинаться с 1*(SP | HT).
message-header :: = field-name ":" [ field-value ] CRLF
field-name :: = token
field-value :: = *( field-content | LWS )
field-content :: = <октеты, составляющие значение поля и
состоящие либо из *TEXT, либо из комбинаций
token, tspecials и quoted-strings>
Порядок полей в заголовке не имеет значения. Но прокси не должен изменять порядок полей в перенаправляемом сообщении.
5.3.3. Тело сообщения
Тело сообщения используется для переноса тела сущности и отличается от тела сущности только когда применено кодирование при передаче.
message-body :: = entity-body | <entity-body закодированное в
соответствии с Transfer-Encoding>
Ответы 1хх (информационные), 204 (нет содержимого) и 304 (не изменен) не должны содержать тело сообщения. Все остальные ответы должны содержать тело, хотя возможно и нулевой длины.
На наличие тела сообщения указывает присутствие полей Content-Length и Transfer-Encoding.
5.3.4. Длина сообщения
При включении тела сообщения в сообщение, длина (конец) этого тела сообщения определяется следующим образом:
1. Любой ответ, который не должен содержать тело сообщения, всегда заканчивается первой пустой строкой после заголовка, независимо от того, присутствуют ли поля заголовка сущности.
2. Если присутствует поле заголовка Transfer-Encoding и указывает на применение порционного кодирования, то длина определяется порционным кодированием.
3. Если присутствует поле Content-Length, его значение определяет длину тела сообщения в байтах.
4. Если сообщение использует тип информации "multipart/byteranges", который является самоограничивающимся, то этот тип информации определяет длину тела сообщения. Этот тип информации должен использоваться сервером только тогда, когда в запросе присутствует заголовок Range с несколькими определителями byte-range, который показывает, что клиент может обработать ответ "multipart/byteranges".
5. Закрытием соединения (только для тела ответа).
Сообщения не должны содержать одновременно поле Content-Length и поля порционного кодирования. В случае получения подобного сообщения значение Content-Length должно игнорироваться.
5.3.5. Общие поля заголовка
Данные поля используются и в запросах, и в ответах и применяются к сообщению в целом, а не к передаваемым сущностям.
general-header :: = Cache-Control
| Connection
| Date
| Pragma
| Transfer-Encoding
| Upgrade
| Via
Нераспознанные поля заголовка должны обрабатываться как поля заголовка сущности.
5.4. Запрос
Сообщение запроса содержит в первой строке сообщения метод, применяемый к ресурсу, идентификатор ресурса и версию используемого протокола.
Request :: = Request-Line
*( general-header
| request-header
| entity-header )
CRLF
[ message-body ]
5.4.1. Request-Line (Строка запроса)
Request-Line начинается с метки метода, за которым следует Request-URI и версия протокола, заканчивающаяся CRLF. Элементы разделены символами SP. Появление символов CR или LF, кроме заключительной последовательности CRLF, запрещено.
Request-Line :: = Method SP Request-URI SP HTTP-Version CRLF
5.4.1.1. Method (Метод)
Регистр символа слова, обозначающего метод, является существенным.
Method :: = "OPTIONS"
| "GET"
| "HEAD"
| "POST"
| "PUT"
| "DELETE"
| "TRACE"
| extension-method
extension-method :: = token
Поддержка методов GET и HEAD является обязательной для реализации сервера.
5.4.1.2. Request-URI (URI запроса)
Request-URI определяет ресурс, к которому применяется запрос.
Символ “*” показывает, что запрос должен применяться не к отдельному ресурсу, а к серверу вцелом.
Request-URI :: = "*" | absoluteURI | abs_path
5.4.2. Идентификация ресурса
Если сервер-источник различает ресурсы на основе запрашиваемого узла (например, поддерживает виртуальные имена узлов), он должен использовать следующие правила для определения запрашиваемого источника.
5.4.2. 1. Если Request-URI является absoluteURI, тогда имя узла является частью Request-URI, и поле Host должно игнорироваться.
5.4.2. 2. Если Request-URI не является absoluteURI, и запрос включает поле заголовка Host, узел определяется значением Host.