- From: Roy T.Fielding <fielding@gbiv.com>
- Date: Sat, 25 Jul 2009 23:32:33 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Jun 28, 2009, at 7: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: That is correct. Content-MD5 is a MIME header referring to the content of a specific body-part (or the entire body if it is in the main headers). If folks want to define a resource metadata header for a hash on the entire representation, then I suggest one be defined or use one of the many defined elsewhere (algorithm-independent, of course). Just don't use the "Content-" prefix on the name. > 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. Toss the MD5s unless it plans to recompose them. > 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)? It is a MIME header field. (a) is the definition. ....Roy
Received on Sunday, 26 July 2009 06:32:44 UTC