Длина содержимого

Содержимое поля заголовка объекта ContentLength указывает длину тела сообщения в октетах (десятичное число), посылаемое получателю, или в случае метода HEAD — размер тела объекта, который мог бы быть послан при запросе GET.

ContentLength = "ContentLength" ":" 1*DIGIT

Например:

ContentLength: 3495

Приложениям следует использовать это поле для указания размера сообщения, которое должно быть послано, вне зависимости от типа среды. Получатель должен иметь возможность надежно определить положение конца запроса HTTP/1.1, содержащего тело объекта, например, запрос использует Transfer-Encoding chunked или multipart body. Любое значение ContentLength, большее или равное нулю, допустимо.

Замечание. Значение этого поля заметно отличается от соответствующего определения в MIME, где оно является опционным, используемым в типе содержимого message/externalbody. В HTTP его следует посылать всякий раз, когда длина сообщения должна быть известна до начала пересылки.

Поле Content-Location

Поле заголовка объекта Content-Location может быть применено для определения положения ресурса для объекта, вложенного в сообщение. В случае, когда ресурс содержит много объектов и эти объекты в действительности имеют разные положения, по которым может быть осуществлен доступ, сервер должен предоставить поле Content-Location для конкретного варианта, который должен быть прислан. Кроме того, сервер должен предоставить Content-Location для ресурса, соответствующего объекту отклика.

Content-Location = "Content-Location" ":" ( absoluteURI | relative-URI )

Если поле заголовка Content-Base отсутствует, значение Content-Location определяет также базовый URL для объекта.

Значение Content-Location не является заменой для исходного запрашиваемого URI, это лишь объявление положения ресурса, соответствующего данному конкретному объекту в момент запроса. Будущие запросы могут использовать Content-Location URI, если нужно идентифицировать источник конкретного объекта.

Кэш не может предполагать, что объект с полем Content-Location, отличающимся от URI, который применялся для его получения, может использоваться для откликов на последующие запросы к этому Content-Location URI. Однако Content-Location может быть нужен для того, чтобы отличить объекты, полученные из одного общего ресурса.

Если Content-Location является относительным URI, URI интерпретируется с учетом значения Content-Base URI, присланного в отклике. Если значения ContentBase не предоставлено, относительный URI интерпретируется по отношению к Request-URI.

Content-MD5

Поле заголовка объекта Content-MD5, как это определено в RFC-1864 [7.23], является MD5-дайджестом тела объекта для целей обеспечения проверки end-to-end целостности сообщения MIC (Message Integrity Check). Проверка MIC привлекательна для регистрации случайных модификаций тела объекта при транспортировке, но не является гарантией против преднамеренных действий.

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

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

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

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

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

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

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