- From: Yves Lafon <ylafon@w3.org>
- Date: Fri, 24 Jul 2009 04:18:08 -0400 (EDT)
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Larry Masinter <LMM@acm.org>
On Thu, 23 Jul 2009, Henrik Nordstrom wrote: > mån 2009-06-29 klockan 12:00 +1000 skrev Mark Nottingham: >> 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: > > RFC2616 can apparently be read both ways depending on which parts of the > specs you read, which is a bit of a problem for Content-MD5. > > My reading is that Content-MD5 is computed on the variant and not the > message-body. The reasoning behind this are: > > * 206 is talked about to only contain ranges of the entity-body > (which btw conflicts with the general messaging format > definition of entity-body making 206 a special case).p4 4. > Combining Ranges 206 is indeed a very special case. > * How partial responses including their headers may be combined. > p4 4. Combining Ranges Same for CL (which can be extracted form Content-Range) There is indeed a story to be told about combining partial responses when Content-MD5 is there (or we can forbid C-MD5 in partial responses) > * It being an Entity-Header. p3 5.8 Content-MD5 Well, Content-Length is also an entity header, however it applies to the transferred bytes in case of 206. What would be the use of C-MD5 if it applies to the whole bag of bytes when you only get a part of it? It can't serve its purpose which is integrity verification, so it makes far more sense if C-MD5 is applied to the transferred bytes, like C-Length > * That sending Entity-Headers is forbidden in an conditional 206 > response (MUST/SHOULD NOT) and required to be included in > unconditional 206 responses if it would have been sent in an 200 > response. > * > * > > > -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Received on Friday, 24 July 2009 08:18:19 UTC