- 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