Протокол HTTP 1.1

радиолиниями и неустойчивой связью. Цель HTTP/1.1 состоит в поддержании

широкого многообразия конфигураций, уже построенных при введении ранних

версий протокола, а также в удовлетворении потребностей разработчиков web

приложений, требующих все более высокой надежности.

HTTP соединение обычно происходит посредством TCP/IP соединений.

Заданный по умолчанию порт TCP - 80, но могут использоваться и другие порты

(например: 8080, 8081). HTTP также может быть реализован посредством любого

другого протокола Интернет, или других сетей. HTTP необходима только

надежная передача данных, следовательно может использоваться любой

протокол, который гарантирует надежную передачу данных; отображение

структуры запроса и ответа HTTP/1.1 на транспортные модули данных

рассматриваемого протокола - вопрос, не решается на уровне самого

протокола.

Большинство реализаций HTTP/1.0 использовало новое соединение для

каждого обмена запросом/ответом. В HTTP/1.1, установленное соединение может

использоваться для одного или нескольких обменов запросом/ответом, хотя

соединение может быть закрыто по ряду причин.

3. Параметры протокола.

3.1 Версия HTTP.

HTTP использует схему нумерации типа ".", для указания

версии протокола. Стратегия версификации протокола предназначена для того,

чтобы позволить отправителю указать формат сообщения и свои способности

понимания для дальнейшей HTTP связи, прежде чем он получит что-либо

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

воздействуют на процесс связи, или компонентов, которые добавляются только

к расширяемым значениям поля, номер версии не меняется. Когда внесенные в

протокол изменения добавляют возможности, которые не изменяют общий

алгоритм анализа сообщений, но расширяют семантику сообщения и

подразумевают дополнительные возможности отправителя, увеличивается

номер. Когда изменяется формат сообщения протокола увеличивается

номер.

Версия HTTP сообщения обозначается полем HTTP-version в первой строке

сообщения.

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

Major и minor числа должны обрабатываться как отдельные целые числа и

что каждое может состоять более чем из одной цифры. Таким образом, HTTP/2.4

- более низкая версия, чем HTTP/2.13, которая в свою очередь ниже чем

HTTP/12.3. Нули должны игнорироваться получателями и не должны посылаться.

Приложения, посылающие сообщения запросов или ответов, которые

описывает спецификация HTTP/1.1, должны указывать версию HTTP (HTTP-

version) "HTTP/1.1". Использование этого номера версии указывает, что

посылающее приложение по крайней мере условно совместимо с этой

спецификацией.

HTTP версия приложения - это самая высокая HTTP версия, с которой

приложение является по крайней мере условно совместимым ним.

Приложения, реализующие прокси-сервера и шлюзы, должны обрабатывать

протокольные сообщения различных версий. Начиная с момента, когда версия

протокола указывает возможности отправителя, прокси-сервер/шлюз никогда не

должен посылать сообщения, версия которых больше, чем HTTP версия

отправителя; если получена более высокая версия запроса, то прокси-

сервер/шлюз должен или понизить версию запроса, вернув сообщение об ошибке,

или переключиться на туннельное поведение. У запросов, версия которых ниже,

чем HTTP версия прокси-сервера/шлюза можно перед пересылкой увеличить

версию; ответ прокси-сервера/шлюза на этот запрос должен иметь ту же самую

major версию, что и запрос.

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

требуемых или запрещенных этими версиями.

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

URI известны под многими именами: WWW адреса, Универсальные

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

в заключение, как комбинация Единообразных Идентификаторов Ресурсов

(Uniform Resource Locators, URL) и Единообразных Имен Ресурсов (Uniform

Resource Names, URN). HTTP определяет URL просто как строку определенного

формата, которая идентифицирует ресурс посредством имени, расположения, или

любой другой характеристики.

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

URI в HTTP могут представляться в абсолютной форме (absolute URI) или

относительно некоторого известного основного URI (relative 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 =

Полная информация о синтаксисе и семантике URL содержится в RFC 1738 и

RFC 1808. Нормальная запись Бекуса-Наура включает национальные символы,

недозволенные в правильных URL, определеных RFC 1738, так как HTTP серверы

позволяют использовать для представления части rel_path адресов набор не

зарезервированных символов, и, следовательно, HTTP прокси-сервера могут

получать запросы URI, не удовлетворяющие RFC 1738.

Протокол HTTP не накладывает никаких ограничений на длины URI. Серверы

должны обрабатывать URI любого ресурса, любой длинны, который они

обслуживают, и им надлежит обрабатывать URI неограниченной длины, если они

обслуживают сервера, основанные на методе GET, которые могут создавать

такой URI. Серверу следует возвращать код состояния 414 (URI запроса

слишком длинный, Request-URI Too Long), если URI длиннее, чем сервер в

состоянии обработать.

Серверы должны обращать внимание на URI, которые имеют длину более 255

байтов, потому что некоторые старые клиенты или прокси-сервера могут

неправильно поддерживать эти длины.

3.2.2 HTTP URL.

"Http" схема используется для доступа к сетевым ресурсам при помощи

протокола HTTP. Этот раздел определяет схемо-определенный синтаксис и

семантику для HTTP URL.

http_URL = "http:" "//" host [ ":" port ] [ abs_path ]

host =

port = *DIGIT

Если порт пуст или не задан - используется порт 80. Это означает, что

идентифицированный ресурс размещен в сервере, ожидающем TCP соединений на

специфицированном порте port, компьютера host, и запрашиваемый URI ресурса

- abs_path. Использования IP адресов в URL следует избегать, насколько это

возможно (RFC 1900). Если abs_path не представлен в URL, он должен

рассматриваться как "/" при вычислении запрашиваемого URI (Request-URI)

ресурса.

3.2.3 Сравнение URI.

При сравнении двух URI, чтобы решить соответствуют ли они друг другу

или нет, клиенту следует использовать чувствительное к регистру пооктетное

(octet-by-octet) сравнение этих URI, со следующими исключениями:

- Порт, который пуст или не указан, эквивалентен заданному по умолчанию

порту для этого URI;

- Сравнение имен хостов должно производиться без учета регистра;

- Сравнение имен схем должно производиться без учета регистра;

- Пустой abs_path эквивалентен "/".

- Символы, отличные от тех, что находятся в "зарезервированных"

("reserved") и "опасных" ("unsafe") наборах эквивалентны их

представлению как ""%" HEX HEX ".

Например следующие три URI эквивалентны:

http://abc.com:80/~smith/home.html

http://ABC.com/%7Esmith/home.html h

ttp://ABC.com:/%7esmith/home.html

3.3 Форматы даты/времени.

3.3.1 Полная дата.

HTTP приложения исторически допускали три различных формата для

представления даты/времени:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, дополненный в ; RFC 1123

Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, переписанный как ; RFC 1036

Sun Nov 6 08:49:37 1994 ; формат asctime() ANSI C

Первый формат выбран в качестве стандарта Интернета и представляет

подмножество фиксированной длины, как определено в RFC 1123

(модифицированном RFC 822). Второй формат находится в общем пользовании, но

основан на устаревшем и потерявшем статус стандарта RFC 850, описывающем

форматы дат, он обладает тем недостатком, что год указывается не в

четырехразрядной нотации. Клиенты и серверы HTTP/1.1, которые анализируют

значение даты, должны понимать все три формата (для совместимости с

HTTP/1.0), но генерировать для представления значений дат в полях заголовка

HTTP должны только формат RFC 1123 .

Прис оздании приложений, желательно, чтобы оно умело воспринимать

значения дат, которые, возможно, посланы не HTTP приложениями, а например

SMTP или NNTP сообщений через прокси-сервера/шлюзы.

Все без исключений форматы даты/времени в HTTP должны быть

представлены в Greenwich Mean Time (GMT). В первых двух форматах данный

факт указывается включением трехсимвольного сокращения "GMT" в качестве

часового пояса. В asctime() формате это ДОЛЖНО подразумеваться при чтении.

HTTP-date = rfc1123-date | rfc850-date | asctime-date

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"

Это требования формата даты/времени, которые применяются внутри потока

протокола HTTP. Клиентам и серверам не требуется использовать эти форматы

для представления пользователю, регистрации запросов и т.д.

3.3.2 Разность секунд (delta seconds).

Некоторые поля HTTP заголовка позволяют указывать значения времени в

виде целого числа секунд, представленного в десятичной форме, которые

должны пройти с того момента, как сообщение было получено.

delta-seconds = 1*DIGIT

3.4 Кодовые таблицы (character sets).

HTTP использует то же самое определение термина "кодовая таблица",

которое определено для MIME:

Термин "кодовая таблица" используется, чтобы сослаться на метод,

использующий одну или несколько таблиц для преобразования

последовательности октетов в последовательность символов. Стоит отметить,

что однозначное преобразование в обратном направлении не требуется, и что

не все символы могут быть доступны в данной кодовой таблице, и что кодовая

таблица может обеспечивать более чем одну последовательность октетов для

представления специфических символов. Это определение допускает различные

виды кодирования символов, от простых однотабличных отображений типа US-

ASCII до сложных методов, переключающих таблицы, наподобие тех, которые

используют методики ISO 2022. Однако определение, связанное с именем

кодовой таблицы MIME должно полностью определять отображение, которое

преобразует октеты в символы. В частности использование внешней информации

профилирования для определения точного отображения не разрешается.

Кодовые таблицы HTTP идентифицируются лексемами, не чувствительными к

регистру. Полный набор лексем определен реестром кодовых таблиц IANA [19].

charset = token

Хотя HTTP позволяет использовать в качестве значения charset

произвольную лексему, любая лексема, которая имеет предопределенное

значение в реестре кодовых таблиц IANA, должна представлять набор символов,

определенный в данном реестре. Приложениям следует ограничить использование

символьных наборов теми, которые определены в реестре IANA.

3.5 Кодирования содержимого (content codings).

Значение кодирования содержимого указывает какое преобразование

кодирования было или будет применено к объекту. Кодирование содержимого

используется прежде всего для сжатия или другого полезного преобразования

документа без потери идентификации основного медиатипа и информации. Часто,

объект сохраняется в кодированной форме, затем передается, а потом

декодируется получателем.

content-coding = token

Все значения кодирования содержимого (content-coding) не чувствительны

к регистру. HTTP/1.1 использует значения кодирования содержимого (content-

coding) в полях заголовка Accept-Encoding и Content-Encoding. Хотя значение

описывает кодирование содержимого, но, что более важно - оно указывает,

какой механизм декодирования потребуется для обратного процесса.

Internet Assigned Numbers Authority (IANA) действует как реестр для

значений лексем кодирования содержимого (content-coding). Первоначально

реестр содержал следующие лексемы:

gzip Формат кодирования, производящий сжатие файла программой "gzip"

(GNU zip), описанный в RFC 1952. Это формат Lempel-Ziv кодирования

(LZ77) с 32 разрядным CRC.

compress Формат кодирования, производимый общей программой "compress"

для сжатия UNIX файлов. Это формат адаптивного Lempel-Ziv-Welch

кодирования (LZW).

Конечно, использовать названия программ для идентификации форматов

кодирования не желательно и может пересекаться с форматами, которые

возникнут в последствии. Их использование объясняется исторической

практикой. Для совместимости с предыдущими реализациями HTTP, приложения

должны рассматривать "x-gzip" и "x-compress" как эквиваленты "gzip" и

"compress" соответственно.

deflate Формат zlib, определенный в 1950, в комбинации с механизмом

сжатия "deflate", описанным в RFC 1951.

Новая лексема значения кодирования содержимого (content-coding) должна

быть зарегистрирована; чтобы обеспечить взаимодействие между клиентами и

серверами, спецификация алгоритма кодирования содержимого, необходимого для

определения нового значения, должна быть открыто опубликована и адекватна

для независимой реализации, а также соответствовать цели кодирования

содержимого определенного в этом разделе.

3.6 Кодирования передачи (Transfer Codings).

Значения кодирования передачи используются для указания преобразования

кодирования, которое было или должно быть применено к телу объекта (entity-

body) в целях гарантирования "безопасной передачи" по сети. Оно отличается

от кодирования содержимого тем, что кодирование передачи - это свойство

сообщения, а не первоначального объекта.

transfer-coding = "chunked" | transfer-extension

transfer-extension = token

Все значения кодирования передачи (transfer-coding) не чувствительны к

регистру. HTTP/1.1 использует значения кодирования передачи (transfer-

coding) в поле заголовка Transfer-Encoding.

Кодирования передачи - это аналоги значений Content-Transfer-Encoding

MIME, которые были разработаны для обеспечения безопасной передачи двоичных

данных при использовании 7-битного обслуживания передачи. Однако безопасный

транспорт имеет другое предназначение для чисто 8-битного протокола

передачи. В HTTP единственная опасная характеристика тела сообщения вызвана

сложностью определения точной длины тела сообщения, или желанием шифровать

данные при пользовании общедоступным транспортом.

Кодирование по кускам (chunked encoding) изменяет тело сообщения для

передачи его последовательностью кусков, каждый из которых имеет

собственный индикатор размера, сопровождаемым опциональным завершителем,

содержащим поля заголовка объекта. Это позволяет динамически создаваемому

содержимому передаваться вместе с информацией, необходимой получателю для

проверки полноты получения сообщения.

Chunked-Body = *chunk "0" CRLF footer CRLF

chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF

hex-no-zero =

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

Кодирование по кускам (chunked encoding) оканчивается куском нулевого

размера, следующим за завершителем, оканчивающимся пустой строкой. Цель

завершителя состоит в эффективном методе обеспечения информации об объекте,

который сгенерирован динамически; приложения не должны посылать в

завершителе поля заголовка, которые явно не предназначены для использования

в завершителе, такие как Content-MD5 или будущие расширения HTTP для

цифровых подписей и других возможностей.

Все HTTP/1.1 приложения должны быть в состоянии получать и

декодировать кодирование передачи "по кускам" ("chunked" transfer coding),

и должны игнорировать расширения кодирования передачи, которые они не

понимают. Серверу, который получил тело объекта со значением кодирования

передачи, которое он не понимает, следует возвратить ответ с кодом 501 (Не

реализовано, Not Implemented) и разорвать соединение. Сервер не должен

посылать поля кодирования передачи (transfer-coding) HTTP/1.0 клиентам.

3.7 Медиатипы (Media Types).

HTTP использует МедиаТипы Интернета (Internet Media Types) в полях

заголовка Content-Type и Accept для обеспечения открытой и расширяемой

типизации данных и типов.

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

= token

Параметры могут следовать за type/subtype в форме пар атрибут/значение

(attribute/value).

parameter = attribute "=" value attribute = token value = token |

quoted-string

Тип, подтип, и имена атрибутов и параметров не чувствительны к

регистру. Значения параметров могут быть чувствительными к регистру, но

могут быть и не чувствительны, в зависимости от семантики имени параметра.

Линейный пробел (LWS) не должен использоваться между типом и подтипом,

между атрибутом и значением. Агенты пользователей, распознающие медиатипы,

должны обрабатывать (или подготавливать для обработки любыми внешними

приложениями) параметры для тех типов MIME, которые описаны, и сообщать

пользователю об обнаруженных проблемах.

Некоторые старые HTTP приложения не распознают параметры медиатипов.

При посылке данных к таким HTTP приложениям реализации должны использовать

Страницы: 1, 2, 3, 4, 5, 6, 7, 8