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

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

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

6.2. Параметры протокола. Версия 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 часть версии сервера и запроса должны совпадать.

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