Гипертекстный протокол HTTP

Соглашения по нотации и общая грамматика. Расширенные BNF

Все механизмы, специфицированные ниже, описаны с использованием обычного текста и расширенных форм Бахуса­Наура BNF (BackusNaur Form; см. RFC-822). Пользователи должны быть знакомы с этой нотацией для понимания данной спецификации. Расширение BNF включает в себя следующие конструкции.

name = definition

Имя правила не требует помещения в угловые скобки. Некоторые базовые правила записываются прописными буквами, например, SP, LWS, HT, CRLF, DIGIT, ALPHA и пр.

literal

Двойные кавычки используются для выделения символьного текста.

rule1 | rule2

Элементы, разделенные вертикальной чертой, ( | ) являются альтернативными, например, "yes | no" допускает yes или no (да или нет).

(rule1 rule2)

Элементы, помещенные в круглые скобки, рассматриваются как один элемент. Так, "(elem (foo | bar) elem)" допускают последовательности "elem foo elem" и "elem bar elem".

*rule

Символ "*", предшествующий элементу, указывает на повторение. Полная форма "<n>*<m>element" указывает как минимум на <n> и как максимум <m> повторений элемента. Значения по умолчанию равны 0 и бесконечности, так что запись "*(элемент)" допускает любое число повторений, включая ноль; "1*element" требует, по меньшей мере, один; а "1*2element" допускает один или два элемента.

[rule]

В квадратные скобки заключаются опционные элементы; [foo bar] эквивалентно *1(foo bar).

n rule

Специальный повтор: <n>(элемент) эквивалентно <n>*<n>(элемент); то есть, точно <n>(element). Таким образом, 2DIGIT является 2-значным числом, а 3ALPHA представляет собой строку из трех буквенных символов.

#rule

Конструкция "#" определена подобно "*", для описания списка элементов. Полная форма имеет вид "<n>#<m>element", отмечая, по меньшей мере <n> и по большей — <m> элементов, отделенных друг от друга одной или более запятыми (",") и опционно строчным пробелом (LWS — Linear White Space). Это делает обычную форму списков очень простой. Запись (*LWS элемент (*LWS элемент *(*LWS "," *LWS элемент)) может быть представлена, как 1#element.

Всюду, где используется эта конструкция, допускаются нулевые элементы, но они не учитываются при подсчете элементов. То есть, допускается запись "(элемент), (элемент)", но число элементов при этом считается равным двум. Следовательно, там, где необходим хотя бы один элемент, должен присутствовать, по крайней мере, один ненулевой элемент. Значениями по умолчанию являются 0 и бесконечность, таким образом "#элемент" допускает любое число, включая нуль; "1#элемент" требует, по меньшей мере один, а "1#2элемент" допускает один или два.

; комментарий

Точка с запятой, смещенная вправо от линейки текста, открывает комментарий, который продолжается до конца строки. Это простой способ включения замечаний в тексты спецификаций.

implied *LWS

Грамматика, описанная в данной спецификации, ориентирована на слова. Если не оговорено обратного, строчный пробел (LWS) может быть заключен между любыми двумя соседними словами (лексема или заключенная в кавычки строка), и между смежными лексемами ( token ) и разделителями ( TSpecials ) без изменения интерпретации поля. По крайней мере один разграничитель ( TSpecials ) должен присутствовать между любыми двумя лексемами, так как они иначе будут интерпретироваться как одна.

Основные правила

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

OCTET      = <любая 8битовая последовательность данных>
CHAR      = <любой символ USASCII (октеты 0  127)>
UPALPHA      = <любая прописная буква USASCII  "A".."Z">
LOALPHA      = < любая строчная буква USASCII "a".."z">
ALPHA      = UPALPHA | LOALPHA (строчная или прописная буква)
DIGIT      = <любая цифра USASCII "0".."9">
CTL        = <любой управляющий символ USASCII (октеты 0  31) и DEL (127)>
CR        = <USASCII CR>, возврат каретки (13)
LF        = <USASCII LF, перевод строки (10)>
SP        = <USASCII SP, пробел (32)>
HT        = <USASCII HT, знак горизонтальной табуляции (9)>
<">  = <USASCII двойная кавычка (34)>

HTTP/1.1 определяет последовательность CR LF как маркер конца для всех протокольных элементов, за исключением тела элемента. Маркер конца строки в пределах тела объекта определен соответствующим типом среды.

CRLF = CR LF

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

LWS = [CRLF] 1*( SP | HT )

Правило TEXT используется только для содержимого описательных полей и значений, которые не предполагается передавать интерпретатору сообщений. Слова *TEXT могут содержать символы из символьного набора, не совпадающего с ISO 88591 [7.22], только когда они закодированы согласно правилам RFC-1522 [7.14].

TEXT = <любой OCTET за исключением CTL, но включая LWS>

В некоторых протокольных элементах используются шестнадцатеричные цифровые символы.

HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

Многие значения полей заголовков HTTP/1.1 состоят из слов, разделенных LWS или специальными символами. Эти специальные символы должны представлять собой строки, заключенные в кавычки, чтобы использоваться в качестве значения параметра.

Token = 1*<любой CHAR за исключением CTL или tspecials>
Tspecials  = "(" | ")" | "<" | ">" | '@"

  | "," | ";" | ":" | "\" | <">

  | "/" | "[" | "]" | "?" | "="

  | "{" | "}" | SP | HT

Комментарии могут быть включены в некоторые поля HTTP заголовков, при этом текст комментария заключается в скобки. Комментарии допустимы только для полей, содержащих comment как часть описания поля. В других полях скобки рассматриваются как элемент содержимого поля.

Комментарий  = "(" *( ctext | комментарий) ")"

ctext  = <любой TEXT, исключая "(" и ")">

Строка текста воспринимается как одно слово, если она помещена в двойные кавычки.

quotedstring  = ( <"> *(qdtext) <"> )

qdtext  = <любой TEXT, исключая <">>

Символ обратная косая черта ( "\" ) может использоваться вместо кавычки внутри закавыченного текста или в структурах комментариев.

quotedpair  = "\" CHAR

Параметры протокола. Версия HTTP

HTTP использует схему нумерации "<major>.<minor>" для отображения версии протокола. Политика присвоения версии протоколу ориентирована на то, чтобы позволить отправителю указать формат сообщения и его емкость. Номер версии не меняется при добавлении компонент сообщения, которые не влияют на характер обмена.

Число <minor> увеличивается, когда в протокол внесены изменения, которые не изменили общий алгоритм разбора сообщений, но изменили семантику сообщений и добавили новые возможности отправителю. Число <major> увеличивается в случае, когда изменен формат протокольного сообщения.

Версия HTTP-сообщения указывается в поле HTTP-Version в первой строке сообщения.

HTTP  Version = "http" "/" 1*DIGIT "." 1*DIGIT

Заметьте, что числа major и minor должны рассматриваться как независимые целые, так что каждое из них может быть увеличено за пределы одной цифры. Таким образом, HTTP/2.4 является более низкой версией, чем HTTP/2.13, которая, в свою очередь, ниже, чем HTTP/12.3. Начальные нули должны игнорироваться и не пересылаться.

Приложения, посылающие запросы или отклики так, как это определено в спецификации, должны включать HTTP-Version "HTTP/1.1". Использование этого номера версии указывает, что посылающее приложение совместимо с этой спецификацией.

Версия HTTP приложения является верхней, совместимость с которой гарантируется. Приложения проксисерверов и сетевых портов должны проявлять осторожность при переадресации сообщений с протокольной версией, отличной от поддерживаемой ими. Так как версия протокола указывает на возможности отправителя, прокси никогда не должны пересылать сообщения с версией больше, чем их собственная; если получено сообщение более высокой версии, прокси/порт должен либо понизить версию запроса, либо послать отклик об ошибке или переключиться в режим туннеля. Запросы с версией ниже, чем у прокси/порта, могут быть повышены при переадресации, при этом major часть версии сервера и запроса должны совпадать.

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

Универсальные идентификаторы ресурсов (URI)

URI известен под многими именами: WWW адрес, универсальный идентификатор документа (Universal Document Identifier), универсальный идентификатор ресурса (Universal Resource Identifier) и, наконец, универсальный локатор ресурса URL (Uniform Resource Locator) и универсальное имя ресурса (URN). Тождество URI и URL сомнительно, так как URL является частным случаем URI. Что касается HTTP, универсальный идентификатор ресурса представляет собой форматированную строку символов, которая идентифицирует имя, положение или какие-­то еще характеристики ресурса.

Общий синтаксис

URI в HTTP может быть представлен в абсолютной или относительной форме по отношению к некоторому известному базовому URI, в зависимости от контекста его использования. Эти две формы отличаются тем, что абсолютный URI всегда начинается с имени схемы, за которым следует двоеточие (например, HTTP: или FTP:).

URI  = ( absoluteURI | relativeURI ) [ "#" фрагмент ]
AbsoluteURI  = схема ":" *( uchar | reserved )
RelativeURI  = net_path | abs_path | rel_path
net_path  = "//" net_loc [ abs_path ]
abs_path  = "/" rel_path
rel_path  = [ проход ] [ ";" params ] [ "?" query ]
path  = fsegment *( "/" сегмент )
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, 
  зарезервированный, extra, safe и unsafe>

Более детальную информацию о синтаксисе и семантике URL можно найти в RFC-1738 [7.4] и [7.11]. Приведенные выше BNF включают в себя национальные символы, недопустимые в URL, как это специфицировано в RFC- 1738, так как серверам HTTP не запрещено использование любых наборов символов, допустимых в rel_path частях адресов; HTTPпрокси могут получить запросы URI, не определенные в рамках RFC-1738.

Протокол HTTP не устанавливает каких-­либо ограничений на длину URI. Серверы должны быть способны обрабатывать URI любых ресурсов, имеющих любую длину. Сервер должен выдать отклик 414 (Request-URI Too Long — URI запроса слишком длинен), если URI длиннее, чем может обработать сервер.

Серверы должны избегать использования URI длиннее 255 байт, так как некоторые старые клиенты или проксиприложения не могут корректно работать с такими длинами.

HTTP URL

Схема HTTP используется для локализации сетевых ресурсов с помощью протокола HTTP. Далее определены синтаксис и семантика HTTP URL, зависящие от схемы.

http_URL  = "http:" "//" host [ ":" port ] [ abs_path ]
Host  = <Легальное имя ЭВМ в Интернет или IP-адрес (в точечно­цифровой форме), 
как это определено в разделе 2.1 RFC-1123>
Port  = *DIGIT

Если номер порта не указан, предполагается порт 80. Семантика устроена так, что идентифицированный ресурс размещается на сервере, который ожидает TCP-соединения через порт данной ЭВМ, а Request-URI для ресурса находится в abs_path. Использование IP адресов в URL следует избегать всюду, где это возможно (см. RFC-1900 [7.24]). Если abs_path в URL отсутствует, он должен считаться равным "/", в случае, если он используется в качестве Request-URI для ресурса.

Сравнение URI

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

• номер порта не указан, тогда для данного URI берется значение по умолчанию;
• сравнение имен ЭВМ и схем не должно быть чувствительным к строчным/прописным буквам;
• Пустой abs_path эквивалентен abs_path "/".

Символы, отличные от типов reserved и unsafe, устанавливаются равными их эквивалентам в кодировке ""%" HEX HEX". Например, следующие три записи URI являются эквивалентными:

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7Esmith/home.html