- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 27 Mar 2011 16:18:48 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Sunday, 27 March 2011 14:19:19 UTC