Транспортное кодирование

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

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]. Использование незарегистрированных типов среды настоятельно не рекомендуется.