W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Content-MD5 and partial responses

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 29 Jun 2009 12:00:01 +1000
Message-Id: <D689800C-3AD4-44A8-B5C6-CB8DF6D786F9@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Larry Masinter <LMM@acm.org>
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/
Received on Monday, 29 June 2009 02:00:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:04 GMT