Протоколы Internet


Гипертекстный протокол HTTP - часть 101


/p>

Поле заголовка Content-MD5 может генерироваться исходным сервером с целью проверки целостности тел объектов. Только исходные серверы могут генерировать поле заголовка Content-MD5. Прокси и внешние шлюзы его генерировать не должны, так как это сделает невозможными проверку целостности end-to-end. Любой получатель тела объекта, включая внешние шлюзы и прокси, могут проверять то, что значение дайджеста в этом поле заголовка согласуется с полученным телом объекта.

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

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

HTTP расширяет RFC 1864 с тем, чтобы разрешить вычисление дайджеста для MIME-комбинации типов среды (например, multipart/* и message/rfc822), но это никак не влияет на способ вычисления дайджеста, описанного выше.

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

Замечание. Так как определение Content-MD5 является в точности тем же для HTTP и MIME (RFC 1864), существует несколько вариантов, в которых применение Content-MD5 к телам объектов HTTP отличается от случая MIME. Один вариант связан с тем, что HTTP, в отличие от MIME, не использует Content-Transfer-Encoding, а использует Transfer-Encoding и Content-Encoding. Другой - вызван тем, что HTTP чаще, чем MIME, использует двоичный тип содержимого. И, наконец, HTTP позволяет передачу текстовой информации с любым типом разрыва строк, а не только с каноническим CRLF. Преобразование всех разрывов строк к виду CRLF не должно делаться до вычисления или проверки дайджеста: тип оформления разрыва строк при расчете дайджеста должен быть сохранен.




Начало  Назад  Вперед