- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 8 Oct 2009 11:56:41 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Thursday, 8 October 2009 00:57:17 UTC