RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

14.16. Content-MD5

Полем заголовка объекта Content-MD5, как определено в RFC 1864 [23], является digest MD5 тела объекта с целью предоставления непрерывной проверки целостности сообщения (МИКРОСХЕМА MIC) тела объекта.

Примечание: МИКРОСХЕМА MIC хороша для того, чтобы обнаружить случайную модификацию тела объекта в пути, но не является доказательством против опасных атак.

Content-MD5   = "Content-MD5" ":" md5-digest
md5-digest    = <base64 of 128 bit MD5 digest as per RFC 1864>

Поле заголовка Content-MD5 может быть сгенерировано сервером происхождения, чтобы функционировать как проверка целостности тела объекта. Только серверы происхождения могут генерировать поле заголовка Content-MD5; прокси и шлюзы не ДОЛЖНЫ генерировать его, поскольку это победило бы его значение как непрерывную проверку целостности. Любой получатель тела объекта, включая шлюзы и прокси, МОЖЕТ проверить что значение digest в этих соответствиях поля заголовка то из тела объекта как получено.

digest MD5 вычислен основанный на контенте тела объекта, включая любой Content-Encoding, который был применен, но не включение любого Transfer-Encoding, который, возможно, применили к телу сообщения. Если сообщение получено с Transfer-Encoding, то кодирование должно быть удалено до проверки значения Content-MD5 против полученного объекта.

У этого есть результат, что digest вычислен на октетах тела объекта точно как, и в порядке, который, их отправили бы, если бы номер Transfer-Encoding применялся.

HTTP распространяет RFC 1864, чтобы разрешить digest быть вычисленным для типов информации составного объекта MIME (например, multipart/* и message.html822), но это не изменяется, как digest вычислен как определено в предыдущем абзаце.

Обратите внимание: Есть несколько последствий этого. Тело объекта для составных типов может содержать многих body-parts, каждый с его собственным MIME и заголовками HTTP (включение Content-MD5, Content-Transfer-Encoding, и заголовков Content-Encoding). Если у части тела есть ContentTransfer-кодирование или заголовок Content-Encoding, предположено, что контенту части тела применили кодирование, и часть тела включена в Content-MD5, который digest как — то есть, после приложения. Поле заголовка Transfer-Encoding не позволено в пределах body-parts.

Обратите внимание: В то время как определение Content-MD5 — точно то же самое для HTTP как в RFC 1864 для тел объекта MIME, есть несколько способов, по которым приложение Content-MD5 к телам объекта HTTP отличается от его приложения до тел объекта MIME. Каждый — тот HTTP, в отличие от MIME, не использует Content-Transfer-Encoding, и действительно использует Transfer-Encoding и Content-Encoding. Другой — тот HTTP, более часто использует двоичные типы контента чем MIME, таким образом он стоит отмечать, что в таких случаях порядок байта, используемый, чтобы вычислить digest, является порядком байта передачи, определенным для type. Наконец, HTTP позволяет передачу типов текстов с любым из нескольких соглашений конца строки и не только канонической формы, используя CRLF.

Обратите внимание: Преобразование всех концов строки к CRLF нельзя сделать прежде, чем вычислить или проверить digest: соглашение конца строки, используемое в тексте, фактически переданном, нужно оставить неизменным, вычисляя digest.

Страница 112 из 160

2007 - 2022 © Русские переводы RFC, IETF, ISOC.