Subject: Re: #178: Content-MD5 and partial responses

From: Mark Nottingham <[email-masked]>
Date: Sun, 27 Mar 2011 16:18:48 +0200

A few different solutions have been proposed for this.

An alternate approach would be to deprecate the Content-MD5 header itself, since MD5 is deprecated, other signature mechanisms are being worked on, and the conflicting interpretations of this header make interop difficult.

Thoughts?

On 08/10/2009, at 2:56 AM, Mark Nottingham wrote:

> This was discussed both on-list and in Stockholm; AIUI the current proposal is:
> 
> 1) caches MUST strip the Content-MD5 header when combining 206 responses, and
> 2) origin servers MUST NOT send a Content-MD5 header on 206 responses
> 
> Thoughts?
> 
> 
> On 29/06/2009, at 12:00 PM, Mark Nottingham wrote:
> 
>> After a quick look, my reading is that a Content-MD5 header on a partial response reflects the bytes in that message, rather than the whole (non-partial) response:
>> 
>>> The entity-header field "Content-MD5", as defined in [RFC1864], is an
>>> MD5 digest of the entity-body for the purpose of providing an end-to-
>>> end message integrity check (MIC) of the entity-body.  (Note: a MIC
>>> is good for detecting accidental modification of the entity-body in
>>> transit, but is not proof against malicious attacks.)
>>> 
>>> Content-MD5   = "Content-MD5" ":" OWS Content-MD5-v
>>> Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
>>> 
>>> The Content-MD5 header field MAY be generated by an origin server or
>>> client to function as an integrity check of the entity-body.  Only
>>> origin servers or clients MAY generate the Content-MD5 header field;
>>> proxies and gateways MUST NOT generate it, as this would defeat its
>>> value as an end-to-end integrity check.  Any recipient of the entity-
>>> body, including gateways and proxies, MAY check that the digest value
>>> in this header field matches that of the entity-body as received.
>>> 
>>> The MD5 digest is computed based on the content of the entity-body,
>>> including any content-coding that has been applied, but not including
>>> any transfer-encoding applied to the message-body.  If the message is
>>> received with a transfer-encoding, that encoding MUST be removed
>>> prior to checking the Content-MD5 value against the received entity.
>> 
>> Also, note that a multipart message is allowed to have C-MD5 on individual parts;
>>> The entity-body for composite types MAY contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding headers).
>> 
>> For a multipart/byteranges response, this only helps really if they apply to the individual parts...
>> 
>> However, I'm wondering what a cache should do when combining partial responses that include Content-MD5. This doesn't seem to be addressed in 2616, nor in p5 or p6.
>> 
>> It looks like there are two options here;
>> 
>> a) C-MD5 applies to the bytes in the entity-body (as above), and therefore we need to specify what a cache does with it when it combines partial responses (throw it away?).
>> 
>> b) C-MD5 applies to the *full* response body, avoiding the combination issues, and allowing clients to do a MIC of the full response (assuming they have it), but removing the ability to do a MIC on a partial response on its own.
>> 
>> Anybody aware of C-MD5 being used with partial responses in the wild (I'm looking at you, Adobe)?
>> 
>> Cheers,
>> 
>> --
>> Mark Nottingham     http://www.mnot.net/
>> 
>> 
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 27 Mar 2011 14:26:37 +0000

In message <[email-masked]>, Mark Nottingham wri

>An alternate approach would be to deprecate the Content-MD5 header 
>itself, since MD5 is deprecated [...]

>Thoughts?

Count me in favour, Content-MD5 has never in my mind served any useful
purpose, that did not have a better solution.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.