Протокол HTTP 1.1 - Коммуникации и связь - Скачать бесплатно
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 =
<эээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээээ 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 приложениям реализации должны использовать
параметры медиатипов только тогда, когда это требуется по определению
типа/подтипа.
Значения медиатипов регистрируются Internet Assigned Number Authority
(IANA). Процесс регистрации медиатипа определен в RFC 2048. Использование
не зарегистрированных медиатипов запрещено.
3.7.1 Канонизация и предопределенные значения типа text.
Медиатипы Интернет зарегистрированы в канонической форме. В общем
случае тело объекта, передаваемое HTTP сообщением, должно быть представлено
в соответствующей каноническиой форме до передачи; исключение составляют
типы "text", определяемые в следующем абзаце.
В канонической форме медиаподтипы типа "text" используют CRLF в
качестве метки конца строки. HTTP ослабляет это требование и позволяет
передавать текст размеченный таким образом, что еденичные CR или LF могут
быть метками конца строки, правда это правило должно быть выполнено для
всего тела объекта (entity-body). HTTP приложения должны воспринимать CRLF,
просто CR и просто LF как представление конца строки в текстовых типах,
переданных по HTTP. Кроме того, если текст представляется в кодовой
таблице, которая не использует октеты 13 и 10 для CR и LF соответственно,
что имеет место в некоторых многобайтовых кодовых таблицах, то HTTP
позволяет использовать любые последовательности октетов, определенные этим
набором символов для представления эквивалентов CR и LF в качестве кода
конца строки. Эта гибкость в отношении концов строк применима только к
текстовым типам в теле объекта; просто CR или просто LF не должны заменять
CRLF внутри любой управляющей структуры HTTP (например поля заголовка и
разделителей типа multipart).
Если тело объекта кодируется при помощи Content-Encoding, то основные
данные должны быть в определенной выше форме до кодирования.
Параметр "charset" используется с некоторыми медиатипами для указания
кодовой таблицы, используемой для представления данных. Если параметр
"charset" не указан отправителем, то при получении по HTTP медиаподтипы
типа "text" имеют значение "charset", по умолчанию равное "ISO-8859-1".
Данные в кодовых таблицах или их подмножествах, отличных от "ISO-8859-1",
должны быть помечены соответствующим значением "charset".
Некоторое программное обеспечение HTTP/1.0 неправильно
интерпретировало заголовок Content-Type без параметра "charset", как
означающее "должен предположить получатель". Отправители, желающие
предусмотреть такое поведение могут включать параметр "charset" даже когда
charset равен ISO-8859-1 и должны сделать это, если известно, что это не
запутает получателя.
К сожалению, некоторые старые HTTP/1.0 клиенты не работали правильно с
определением параметра "charset". HTTP/1.1 получатели должны отдавать
приоритет метке "charset", поставленной отправителем; и те агенты
пользователей, которые имеют возможность "предположить" charset должны при
первоначальном отображении документа использовать charset из поля content-
type, если они поддерживают такой charset, а затем использовать собственные
установки.
3.7.2 Типы Multipart.
MIME предусматривает ряд типов "multipart" - формирующих пакет из
одного или нескольких объектов внутри тела одного сообщения. Все типы
mulptipart используют общий синтаксис, определеный в MIME, и должны
содержать разделительный параметр частью значения медиатипа. Тело сообщения
- самостоятельный элемент протокола и, следовательно, должно использовать
только СRLF для представления концов строк между частями тела (body-parts).
В отличие от MIME, заключение (epilogue) любого multipart сообщения должно
быть пустым; HTTP приложения не должны передавать заключение (даже если
первоначальный multipart содержит заключение).
В HTTP части тела (body-parts) типа multipart могут содержать поля
заголовка, которые являются значащими в примнении к этой части. Поле
заголовка Content-Location следует включать в часть тела (body-part)
каждого включенного объекта, который может быть идентифицирован URL.
Вообще говоря, HTTP агенту пользователя належит действовать так же
как поступил бы MIME агент пользователя после получения типа multipart.
Если приложение получает незарегистрированный подтип multipart, оно должно
обрабатывать его как подтип "multipart/mixed".
Тип "multipart/form-data" был специально определен для передачи данных
формы, подходящих для обработки методом запроса POST, что описано в RFC
1867.
3.8 Маркеры продуктов (Product Tokens).
Маркеры продуктов используются, чтобы обеспечить коммуникационным
приложениям возможность идентифицировать себя названием и версией
программного обеспечения. Большинство полей, использующих маркеры продуктов
также допускает перечисление подпрограмм, которые формируют значительную
часть приложения, и которые перечисляются через пробел. В соответствии с
соглашением, подпрограммы перечисляются в порядке их значения для
идентификации приложения.
product = token ["/" product-version] product-version = token
Примеры:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Server: Apache/0.8.4
Маркеры продуктов должны быть короткими и по сути - использование их
для рекламы или другой несущественной информации однозначно запрещено. Хотя
в лексеме product-version может встречаться любой символ, все же ее следует
использовать только для идентификатора версии (то есть, последовательным
версиям одной и той же программы надлежит иметь отличия только в части
product-version лексемы product.
3.9 Величины качества (Quality Values).
HTTP использует короткие числа "с плавающей точкой" для указания
относительной важности ("веса") различных оговоренных параметров. Вес - это
нормализованое вещественное число в диапазоне от 0 до 1, где 0 -
минимальное, а 1 - максимальное значение. HTTP/1.1 приложения не должны
генерировать более трех цифр после десятичной точки. Пользовательским
конфигурациям этих значений следует также ограничиваться этим режимом.
qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] )
"Величины качества" - не корректное название, так как эти значения
просто представляют отношение снижения производительности к желательному
качеству.
3.10 Метки языков (Language Tags).
Метка языка идентифицирует естественный язык: разговорный, письменный,
или другой используемый людьми для обмена информацмей с другими людьми.
Машинные языки являются исключением. HTTP использует метки языков внутри
полей Accept-Language и Content-Language.
Синтаксис и запись меток языка в HTTP те же, что определены в RFC
1766. То есть, метка языка состоит из одной или нескольких частей: метка
первичного языка и, возможно пустой, ряд подчиненных меток:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA subtag = 1*8ALPHA
Внутри метки не допустимы пробелы и все метки не чувствительны к
регистру. Пространство имен меток языка управляется IANA. Например метки
содержат:
en, en-US, en-cockney, i-cherokee, x-pig-latin
Любая двухсимвольная первичная метка является меткой аббревеатуры
языка ISO 639, а любая двухсимвольная подчиненная метка является меткой
кода страны ISO 3166. (Последние три метки из вышеперечисленных - не
зарегистрированные метки; все, кроме последней - примеры меток, которые
скорее всего ьудут зарегистрированы в будущем.)
3.11 Метки объектов (Entity Tags).
Метки объектов используются для сравнения двух или более объектов
одного и того же запрошенного ресурса. HTTP/1.1 использует метки объектов в
полях заголовка ETag, If-Match, If-None-Match, и If-Range. Метка объекта
состоит из непрозрачной строки, заключенной в кавычки (opaque quoted
string), возможно предваренной индикатором слабости (weakness indicator).
entity-tag = [ weak ] opaque-tag
weak = "W/" opaque-tag = quoted-string
"Сильная метка объекта" ("strong entity tag") может быть
распространнена на два объекта ресурса, только тогда, когда они пооктетно
эквивалентны.
"Слабая метка объекта" ("weak entity tag"), обозначяемая префиксом
"W/", может быть распространена на два объекта ресурса только тогда, когда
объекты эквивалентны и могли бы заменять друг друга без значительного
изменения в семантике. Слабая метка объекта может использоваться только для
слабого сравнения (weak comparison).
Метка объекта должна быть уникальна среди всех версий всех объектов,
связанных с конкретным ресурсом. Данное значение метки объекта может
использоваться для объектов, полученных запросами различных URI без
предположения эквивалентности этих объектов.
3.12 Единицы измерения диапазонов (Range Units).
HTTP/1.1 позволяет клиенту запрашивать только часть объекта. HTTP/1.1
использует еденицы измерения диапазонов в полях заголовка Range и Content-
Range. Объект может быть разбит на части соответственно различным
структурным модулям.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes" other-range-unit = token
Единственая еденица измерения диапазонов, определенная в HTTP/1.1 -
это "bytes". Реализации HTTP/1.1 могут игнорировать диапазоны, определенные
с использованием других едениц измерения. HTTP/1.1 был разработан, чтобы
обеспечения возможности реализации приложений, которые не зависят от знания
диапазонов.
4. HTTP сообщение (HTTP Message).
4.1 Типы сообщений.
HTTP сообщения делятся на запросы клиента серверу и ответы сервера
клиенту.
HTTP-message = Request | Response ; сообщения HTTP/1.1
Сообщения запроса и ответа используют обобщенный формат сообщения RFC
822 для пересылки объектов (полезной нагрузки сообщения). Оба типа
сообщений выглядят следующим образом: сначала идет начальная строка (start-
line), затем один или несколько полей заголовка (называемых также просто
"заголовки"), затем пустая строка (то есть строка, равная CRLF),
указывающая конец полей заголовка, а затем, возможно, тело сообщения.
generic-message = start-line *message-header CRLF [ message-body ]
start-line = Request-Line | Status-Line
В интересах ошибкоустойчивости, серверам следует игнорировать все
пустые строки, полученные перед строкой запроса (Request-Line). Другими
словами, если сервер читает поток
|
