Введение кодирования содержимого

MIME не содержит какоголибо эквивалента полю заголовка Content-Encoding HTTP/1.1. Так как это поле работает как модификатор типа среды, прокси и шлюзы между HTTP и MIME протоколами должны или изменить значение поля заголовка Content-Type, или декодировать тело объекта, прежде чем переадресовывать сообщение. Некоторые экспериментальные приложения Content-Type для почты Интернет используют параметр типа среды ";conversions=" для выполнения операции, аналогичной Content-Encoding. Однако этот параметр не является частью MIME.

No Content-Transfer-Encoding

HTTP не использует поле MIME CTE (Content-Transfer-Encoding). Прокси и шлюзы от MIME к HTTP должны удалять любую неидентичность CTE (quoted-printable или base64) кодирования, прежде чем доставлять сообщение­отклик клиенту HTTP.

Прокси и шлюзы от HTTP к MIME ответственны за то, чтобы сообщения имели корректные форматы и кодировки для безопасной транспортировки (безопасная транспортировка определяется ограничениями используемого протокола). Такие прокси и шлюзы должны помечать информацию согласно Content-Transfer-Encoding. Поступая так, мы улучшаем вероятность безопасной транспортировки с применением протокола места назначения.

Поля заголовка в многофрагментных телах

В MIME большинство полей заголовка в многофрагментных частях игнорируются, если только имя поля не начинается с Content. В HTTP/1.1 многофрагментные части тела могут содержать любые поля заголовков HTTP, которые имеют смысл для этой части.

Введение транспортного кодирования

Протокол HTTP/1.1 вводит поле заголовка Transfer-Encoding. Прокси/шлюзы должны удалять любое транспортное кодирование перед переадресацией сообщения через протокол MIME.

Процесс декодирования транспортного кода может быть представлен в виде псевдопрограммы:

length := 0 read chunksize, chunkextention (if any) and CRLF while (chunksize > 0) { read chunkdata and CRLF append chunkdata to entitybody length := length + chunksize read chunksize and CRLF } read entityheader while (entityheader not empty) { append entityheader to existing header fields read entityheader } ContentLength := length Remove "chunked" from Transfer-Encoding

MIME-Version

HTTP не является протоколом, совместимым с MIME. Однако HTTP/1.1 сообщения могут включать поле общего заголовка MIME-Version, чтобы указать, какая версия протокола MIME была использована для конструирования сообщения. Использование заголовка поля MIME-Version отмечает, что сообщение полностью соответствует протоколу MIME. Прокси/шлюзы несут ответственность за полную совместимость (где это возможно), когда осуществляется передача HTTP сообщений в среду MIME.

MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Дополнительные методы запросов Метод patch

Метод PATCH подобен PUT, за исключением того, что объект содержит список отличий между оригинальной версией ресурса, идентифицированного Request-URI, и желательной версией ресурса после операции PATCH. Список отличий записывается в формате, определенном типом среды объекта (например, application/diff), и должен включать достаточную информацию, чтобы позволить серверу выполнить изменения по преобразованию ресурса из исходной версии в заказанную.

Если запрос проходит через кэш и Request-URI идентифицирует объект в кэше, этот объект должен быть удален из кэша. Отклики для этого метода не кэшируются.

Реальный метод определения того, как разместится скорректированный ресурс и что случится с его предшественником, определяется исключительно исходным сервером. Если оригинальная версия ресурса, который предполагается скорректировать, включает в себя поле заголовка Content-Version, объект запроса должен включать поле заголовка Derived-From, соответствующее значению оригинального поля заголовка Content-Version. Приложениям рекомендуется использовать эти поля для работы с версиями с целью разрешения соответствующих конфликтов. Запросы PATCH должны подчиняться требованиям к передаче сообщений. Кэши, которые реализуют PATCH, должны объявить кэшированные отклики недействительными.