Subject: #178: Content-MD5 and partial responses

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Oct 2009 11:56:41 +1100

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/

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 7 Oct 2009 21:20:42 -0500

> 2) origin servers MUST NOT send a Content-MD5 header on 206 responses

Clients also MUST strip/ignore the Content-MD5 header on 206 responses.
The whole point is that the combination of 206 responses and Content-MD5
is not reliable, right?

Regards,
Brian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Oct 2009 13:49:19 +1100

Yep.

---

From: Yves Lafon <[email-masked]>
Date: Thu, 8 Oct 2009 04:05:12 -0400 (EDT)

On Thu, 8 Oct 2009, 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

Should we add that clients MUST ignore Content-MD5 on 206 responses?

>> 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:
>> 
>> 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, 
>> For a multipart/byteranges response, this only helps really if they apply 
>> to the individual parts...
>> 
>> responses that include Content-MD5. This doesn't seem to be addressed in 
>> 2616, nor in p5 or p6.
>> 
>> 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,
>> 
>> --

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Oct 2009 15:03:05 +1100

It seems like we're in agreement about this; assigning for -08.