HTTP/1.1, протокол передачи гипертекста
3 Параметры протокола.
HTTP использует схему нумерации типа "<major>.<minor>", для указания версии протокола. Стратегия версификации протокола предназначена для того, чтобы позволить отправителю указать формат сообщения и свои способности понимания для дальнейшей HTTP связи, прежде чем он получит что-либо посредством этой связи. При добавлении компонентов сообщения, которые не воздействуют на поведение связи, или компонентов, которые добавляются только к расширяемым значениям поля, номер версии не меняется. Когда внесенные в протокол изменения добавляют возможности, которые не изменяют общий алгоритм анализа сообщений, но которые расширяют семантику сообщения и подразумевают дополнительные возможности отправителя, увеличивается <Minor> номер. Когда формат сообщения протокола изменяется увеличивается <Major> номер.
Версия HTTP сообщения обозначается полем HTTP-version в первой строке сообщения.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Обратите внимание, что major и minor числа ДОЛЖНЫ обрабатываться как отдельные целые числа и что каждое может состоять более чем из одной цифры. Таким образом, HTTP/2.4 - более низкая версия, чем HTTP/2.13, которая в свою очередь ниже чем HTTP/12.3. Нули ДОЛЖНЫ игнорироваться получателями и НЕ ДОЛЖНЫ посылаться.
Приложения, посылающие сообщения запросов или ответов, которые описывает эта спецификация, ДОЛЖНЫ включить 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 просто как строку определенного формата, которая идентифицирует - через имя, расположение, или любую другую характеристику - ресурс.
URI в HTTP могут представляться в абсолютной (absolute) форме или относительно некоторой известной основы URI (relative), в зависимости от контекста их использования. Эти две формы различаются тем, что абсолютные 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>
Полную информацию относительно синтаксиса и семантики URL смотрите RFC 1738 [4] И RFC 1808 [11]. Вышеуказанная нормальная запись Бекуса-Наура включает национальные символы, недозволенные в допустимых URL (это определено в RFC 1738, так как HTTP серверы позволяют использовать для представления части rel_path адресов набор незарезервированных символов, и, следовательно, HTTP прокси-сервера могут получать запросы URI, не соответствующие RFC 1738.
Протокол HTTP не накладывает a priori никаких ограничений на длины URI. Серверы ДОЛЖНЫ быть способны обработать URI любого ресурса, который они обслуживают, и им СЛЕДУЕТ быть в состоянии обрабатывать URI неограниченной длины, если они обслуживают формы, основанные на методе GET, которые могут генерировать такой URI. Серверу СЛЕДУЕТ возвращать код состояния 414 (URI запроса слишком длинный, Request-URI Too Long), если URI больше, чем сервер может обработать (смотрите раздел 10.4.15).
Обратите внимание: Серверы должны быть осторожны с URI, которые имеют длину более 255 байтов, потому что некоторые старые клиенты или прокси-сервера не могут правильно поддерживать эти длины.
"Http" схема используется для доступа к сетевым ресурсам при помощи протокола HTTP. Этот раздел определяет схемо-определенный синтаксис и семантику для HTTP URL.
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
host = <допустимое доменное имя машины
или IP адрес (в точечно-десятичной форме),
как определено в разделе 2.1 RFC 1123>
port = *DIGIT
Если порт пуст или не задан - используется порт 80. Это означает, что идентифицированный ресурс размещен в сервере, ожидающем TCP соединений на специфицированном порте port, компьютера host, и запрашиваемый URI ресурса - abs_path. Использования IP адресов в URL СЛЕДУЕТ избегать, когда это возможно (смотрите RFC 1900 [24]). Если abs_path не представлен в URL, он ДОЛЖЕН рассматриваться как "/" при вычислении запрашиваемого URI (Request-URI) ресурса (раздел 5.1.2).
При сравнении двух URI, чтобы решить соответствуют ли они друг другу или нет, клиенту СЛЕДУЕТ использовать чувствительное к регистру пооктетное (octet-by-octet) сравнение этих URI, со следующими исключениями:
- Порт, который пуст или не указан, эквивалентен заданному по умолчанию порту для этого URI;
- Сравнение имен хостов ДОЛЖНО производиться без учета регистра;
- Сравнение имен схем ДОЛЖНО производиться без учета регистра;
- Пустой abs_path эквивалентен "/".
Символы, отличные от тех, что находятся в "зарезервированных" ("reserved") и "опасных" ("unsafe") наборах (см. раздел 3.2) эквивалентны их кодированию как ""%" HEX HEX ".
Например следующие три URI эквивалентны:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
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 [12], описывающем форматы дат, он обладает тем недостатком, что год указывается не в четырехразрядной нотации. Клиенты и серверы 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 и 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 (раздел 14.3) и Content-Encoding (раздел 14.12). Хотя значение описывает кодирование содержимого, но, что более важно - оно указывает, какой механизм декодирования потребуется для обратного процесса.
Internet Assigned Numbers Authority (IANA) действует как реестр для значений лексем кодирования содержимого (content-coding). Первоначально реестр содержал следующие лексемы:
- gzip
- Формат кодирования, производящий сжатие файла программой "gzip" (GNU zip), как описано в RFC 1952 [25]. Это формат Lempel-Ziv кодирования (LZ77) с 32 разрядным CRC.
- compress
- Формат кодирования, производимый общей программой "compress" для сжатия UNIX файлов. Это формат адаптивного Lempel-Ziv-Welch кодирования (LZW).
- deflate
- Формат zlib, определенный в RFC 1950 [31], в комбинации с механизмом сжатия "deflate", описанным в RFC 1951 [29].
Обратите внимание: Использовать названия программ для идентификации форматов кодирования не желательно и должно быть не понятно будущим кодированиям. Их использование здесь объясняется исторической практикой, но так делать не нужно. Для совместимости с предыдущими реализациями HTTP, приложения должны рассматривать "x-gzip" и "x-compress" как эквиваленты "gzip" и "compress" соответственно.
Новая лексема значения кодирования содержимого (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 (раздел 14.40).
Кодирования передачи - это аналоги значений Content-Transfer-Encoding MIME, которые были разработаны для обеспечения безопасной передачи двоичных данных при использовании 7-битного обслуживания передачи. Однако безопасный транспорт имеет другое предназначение для чисто 8-битного протокола передачи. В HTTP единственая опасная характеристика тела сообщения вызвана сложностью определения точной длины тела сообщения (раздел 7.2.2), или желанием шифровать данные при пользовании общедоступным транспортом.
Кодирование по кускам (chunked encoding) изменяет тело сообщения для передачи его последовательностью кусков, каждый из которых имеет собственный индикатор размера, сопровождаемым опциональным завершителем, содержащим поля заголовка объекта. Это позволяет динамически создаваемому содержимому передаваться вместе с информацией, необходимой получателю для проверки полноты получения сообщения.
Chunked-Body = *chunk
"0" CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
hex-no-zero = <HEX за исключением "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
Кодирование по кускам (chunked encoding) оканчивается куском нулевого размера, следующим за завершителем, оканчивающимся пустой строкой. Цель завершителя состоит в эффективном методе обеспечения информации об объекте, который сгенерирован динамически; приложения НЕ ДОЛЖНЫ посылать в завершителе поля заголовка, которые явно не предназначены для использования в завершителе, такие как Content-MD5 или будущие расширения HTTP для цифровых подписей и других возможностей.
Примерный процесс декодирования Chunked-Body представлен в приложении 19.4.6.
Все HTTP/1.1 приложения ДОЛЖНЫ быть в состоянии получать и декодировать кодирование передачи "по кускам" ("chunked" transfer coding), и ДОЛЖНЫ игнорировать расширения кодирования передачи, которые они не понимают. Серверу, который получил тело объекта со значением кодирования передачи, которое он не понимает, СЛЕДУЕТ возвратить ответ с кодом 501 (Не реализовано, Not Implemented) и разорвать соединение. Сервер НЕ ДОЛЖЕН посылать поля кодирования передачи (transfer-coding) HTTP/1.0 клиентам.
HTTP использует Медиа Типы Интернета (Internet Media Types) в полях заголовка Content-Type (раздел 14.18) и Accept (раздел 14.1) для обеспечения открытой и расширяемой типизации данных и обсуждения типов.
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 [17]. Использование не зарегистрированных медиа типов вводит в заблуждение.
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" используется с некоторыми медиа типами для указания кодовой таблицы (раздел 3.4), используемой для представления данных. Если параметр "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, а затем использовать собственные установки.
MIME предусматривает ряд типов "multipart" - формирующих пакет из одного или нескольких объектов внутри тела одного сообщения. Все типы mulptipart используют общий синтаксис, определеный в MIME [7], и ДОЛЖНЫ содержать разделительный параметр частью значения медиа типа. Тело сообщения - самостоятельный элемент протокола и, следовательно, ДОЛЖНО использовать только СRLF для представления концов строк между частями тела (body-parts). В отличие от MIME, окончание любого multipart сообщения ДОЛЖНО быть пустым; HTTP приложения НЕ ДОЛЖНЫ передавать окончание (даже если первоначальный multipart содержит заключение).
В HTTP части тела (body-parts) типа multipart МОГУТ содержать поля заголовка, которые являются значащими в примнении к этой части. Поле заголовка Content-Location (раздел 14.15) СЛЕДУЕТ включать в часть тела (body-part) каждого включенного объекта, который может быть идентифицирован URL.
Вообще говоря, HTTP агенту пользователя СЛЕДУЕТ следовать такому же или подобному поведению, которому следовал бы MIME агент пользователя после получения типа multipart. Если приложение получает незарегистрированный подтип multipart, оно ДОЛЖНО обрабатывать его как подтип "multipart/mixed".
Обратите внимание: тип "multipart/form-data" был специально определен для передачи данных формы, подходящих для обработки методом запроса POST, что описано в RFC 1867 [15].
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 (раздел 12) использует короткие числа "с плавающей точкой" для указания относительной важности ("веса") различных оговоренных параметров. Вес - это нормализованое вещественное число в диапазоне от 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 [1]. В резюме, метка языка состоит из одной или нескольких частей: метка первичного языка и, возможно пустой, ряд подчиненных меток:
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 (раздел 14.20), If-Match (раздел 14.25), If-None-Match (раздел 14.26), и If-Range (раздел 14.27). Определение того, как они используются и сравниваются в качестве меток проверки кэша находится в разделе 13.3.3. Метка объекта состоит из непрозрачной цитируемой строки (opaque quoted string), возможно предваренной индикатором слабости (weakness indicator).
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
"Сильная метка объекта" ("strong entity tag") может быть разделена двумя объектами ресурса, только если они пооктетно эквивалентны.
"Слабая метка объекта" ("weak entity tag"), обозначяемая префиксом "W/", может быть разделена двумя объектами ресурса только если объекты эквивалентны и могли бы заменять друг друга без значительного изменения в семантике. Слабая метка объекта может использоваться только для слабого сравнения.
Метка объекта ДОЛЖНА быть уникальна среди всех версий всех объектов, связанных с конкретным ресурсом. Данное значение метки объекта может использоваться для объектов, полученных запросами различных URI без предположения эквивалентности этих объектов.
3.12 Еденицы измерения диапазонов (Range Units).
HTTP/1.1 позволяет клиенту запрашивать только часть объекта. HTTP/1.1 использует еденицы измерения диапазонов в полях заголовка Range (раздел 14.36) и Content-Range (раздел 14.17). Объект может быть разбит на части соответственно различным структурным модулям.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
Единственая еденица измерения диапазонов, определенная в HTTP/1.1 - это "bytes". Реализации HTTP/1.1 могут игнорировать диапазоны, определенные с использованием других едениц измерения. HTTP/1.1 был разработан, чтобы допускать реализации приложений, которые не зависят от знания диапазонов.
