Форматы даты/времени. Полная дата
HTTP приложения допускают три различных формата для представления метки времени и даты:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC-822, актуализировано в RFC-1123
Sunday, 06Nov94 08:49:37 GMT ; RFC-850, объявлено устаревшим в RFC-1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime()
Первый формат предпочтительнее, как стандарт Интернет и представляет собой форму фиксированной длины, определенную RFC-1123. Второй формат используется достаточно широко, но базируется на устаревшем документе RFC-850 [7.12], формат даты не имеет 4 цифр года. Клиенты и серверы HTTP/1.1, которые анализируют дату, должны уметь работать со всеми тремя форматами (для совместимости с HTTP/1.0), хотя они должны сами генерировать время/дату согласно формату RFC-1123.
Получатели значений даты должны быть готовы принять коды, которые посланы не приложениями HTTP, что случается, когда данные поступают через прокси/порты или по почте в SMTP или NNTP-форматах.
Все метки времени/даты HTTP должны соответствовать времени по Гринвичу (GMT). Это указано в первых двух форматах путем включения строки "GMT" и должно предполагаться во всех прочих случаях.
HTTPdate = RFC-1123date | rRFC-850date | asctimedate
RFC-1123date = wkday "," SP date1 SP time SP "GMT"
RFC-850date = weekday "," SP date2 SP time SP "GMT"
asctimedate = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (\напр., 02 Jun 1982)
date2 = 2DIGIT "" month "" 2DIGIT
; daymonthyear (напр., 02Jun82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (напр., 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 требования для формата метки даты/времени применимы только для использования в рамках реализации самого протокола. Клиенты и серверы не требуют применения этих форматов для пользовательских презентаций, протоколирования запросов и т.д..
Интервалы времени в секундах
Некоторые поля заголовка HTTP допускают спецификацию значения времени в виде целого числа секунд, представленного в десятичной форме и равного времени с момента получения сообщения.
deltaseconds = 1*DIGIT
Наборы символов
HTTP использует то же определение термина "набор символов", что дано для MIME:
Термин "набор символов" относится к методу, который с помощью одной или более таблиц преобразует последовательность октетов в последовательность символов. Заметьте, что не требуется безусловного обратного преобразования, при этом не все символы могут быть доступны и одному и тому же символу может соответствовать более чем одна последовательность октетов. Это определение имеет целью допустить различные виды кодировок символов, от простых однотабличных, таких, как US-ASCII, до сложных — таблично переключаемых методов, используемых, например, в ISO 2022. Однако определение, связанное с набором символов MIME, должно полностью специфицировать схему соответствия октетов и символов. Применение внешних профайлов для определения схемы шифрования недопустимо.
Замечание. Здесь "набор символов" ближе к понятию "кодирование символов". Однако так как HTTP и MIME используют один и тот же регистр, важно, чтобы терминология также была идентичной.
Наборы символов HTTP идентифицируются лексемами, которые не чувствительны к использованию строчных или прописных букв. Полный набор лексем определен регистром наборов символов IANA [7.19].
charset = token
Несмотря на то, что HTTP позволяет использовать произвольную лексему в качестве значения charset, любая лексема, значение которой определено в рамках регистра набора символов IANA, должна представлять символьный набор, определенный этим регистром. Приложение должно ограничить использование символьных наборов только теми, которые определены регистром IANA.
Кодировки содержимого
Значения кодировки содержимого указывают на кодовое преобразование, которое было или может быть выполнено над объектом. Кодировки содержимого первоначально применены для того, чтобы иметь возможность архивировать документ или преобразовать его какимто другим способом без потери идентичности или информации. Часто объект запоминается закодированным, передается и только получателем декодируется.
contentcoding = token
Все значения кодировок содержимого не зависят от того, используются строчные или прописные символы. HTTP/1.1 реализует значения кодировок содержимого в полях заголовка AcceptEncoding и Content-Encoding. Хотя значение описывает кодирование содержимого, более важным является то, что оно определяет механизм декодирования.
Комитет по стандартным числам Интернет IANA (Internet Assigned Numbers Authority) выполняет функции регистра для значений лексем кодирования содержимого. Этот регистр хранит следующие лексемы:
gzip
Формат кодирования, реализуемый программой архивации файлов gzip (GNU zip), как описано в RFC-1952 [7.25]. Этот формат соответствует кодированию LempelZiv (LZ77) с 32 битным CRC.
compress
Формат кодирования, реализуемый стандартной программой UNIX для архивации файлов compress. Этот формат соответствует адаптивному методу кодирования LempelZivWelch (LZW).
Замечание. Использование имен программ для идентификации форматов кодирования нежелательно и будет в будущем заменено. Их использование здесь является следствием исторической практики. Для совместимости с предшествующими реализациями HTTP, приложения должны считать xgzip и xcompress эквивалентными gzip и compress соответственно.
deflate
Формат zlib определен документом RFC-1950 [7.31] в комбинации с механизмом сжатия deflate, описанным в RFC-1951 [7.29].
Транспортное кодирование
Значения транспортного кодирования используются для определения кодового преобразования, которому был подвергнут или желательно подвергнуть объект для того, чтобы гарантировать безопасную его транспортировку через сеть. Этот вид преобразования отличен от кодирования содержимого, так как относится к сообщению, а не к исходному объекту.
Transfercoding = "chunked" | transferextension
Transferextension = token
Все значения транспортного кодирования не зависят от того, строчные или прописные буквы здесь применены. HTTP/1.1 несет значения транспортного кодирования в поле заголовка Transfer-Encoding.
Транспортные кодировки аналогичны используемым значениям ContentTransfer-Encoding MIME, которые были введены для обеспечения безопасной передачи двоичных данных через 7-битную транспортную среду. Однако безопасная транспортировка имеет другие аспекты в рамках 8-битного протокола передачи сообщений. В HTTP единственной небезопасной характеристикой тела сообщения является неопределенность его длины, или желание зашифровать данные при передаче по общему каналу.
Блочное кодирование фрагментов модифицирует тело сообщения для того, чтобы передать его в виде последовательности пакетов, каждый со своим индикатором размера, за которым следует опционная завершающая запись (footer), содержащая поля заголовка объекта. Это позволяет передать динамически сформированное содержимое, снабдив его необходимой информацией для получателя, который, в конце концов, сможет восстановить все сообщение.
Chunked Body = *chunk "0" CRLF footer CRLF
Chunk = chunksize [ chunkext ] CRLF chunkdata CRLF
Hexnozero = <HEX excluding "0">
Chunksize = hexnozero *HEX
Chunkext = *( ";" chunkextname [ "=" chunkextvalue ] )
Chunkextname = token
Chunkextval = token | quotedstring
Chunkdata = chunksize(OCTET)
Footer = *entityheader
Блочное кодирование фрагментов завершается пакетом нулевой длины, за которым следует завершающая запись и пустая строка. Назначение завершающей записи заключается в том, чтобы предоставить информацию о динамически сформированном объекте; приложения не должны пересылать поля заголовка в завершающей записи, кроме тех, которые специально оговорены, например, такие, как Content-MD5 или будущие расширения HTTP для цифровой подписи.
Все приложения HTTP/1.1 должны быть способны получать и декодировать получаемые фрагменты ("chunked"-кодирование) и должны игнорировать расширения транспортного кодирования, которые они не понимают. Сервер, получающий тело объекта с транспортной кодировкой, которую он не понимает, должен отослать отклик c кодом 501 (Unimplemented — не применимо) и закрыть соединение.
Сервер не должен применять транспортное кодирование при посылке данных клиенту HTTP/1.0.
Типы среды
HTTP использует типы среды Интернет (Internet Media Types) в полях заголовка Content-Type и Accept для того, чтобы обеспечить широкий и открытый обмен с самыми разными типами среды.
Mediatype = type "/" subtype *( ";" parameter )
Type = token
Subtype = token
Параметры могут следовать за type/subtype в форме пар атрибут/значение.
Parameter = attribute "=" value
Attribute = token
value = token | quotedstring
Имена типа, субтипа и атрибутов параметра могут набираться как строчными, так и прописными буквами. Значения параметров могут быть и чувствительны к используемому регистру, в зависимости от семантики и имени параметра. Строчный пробел (LWS) не должен использоваться ни между типом и субтипом, ни между атрибутом и значением. Агенты пользователя, которые распознают тип среды, должны обрабатывать (или обеспечить обработку с использованием внешнего приложения для работы агента пользователя с типом/субтипом) параметры для типа MIME так, как это описано для данного типа/субтипа, и информировать пользователя о любых возникающих проблемах.
Некоторые старые приложения HTTP не узнают параметры типа среды. При посылке данных старому HTTPприложению программы должны использовать параметры типа среды, только когда они необходимы по описанию типа/субтипа.
Значения типа среды регистрируются IANA (Internet Assigned Number Authority). Процесс регистрации типа среды описан в RFC-2048 [7.17]. Использование незарегистрированных типов среды настоятельно не рекомендуется.