W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Content-MD5 and partial responses

From: Adrien de Croy <adrien@qbik.com>
Date: Fri, 24 Jul 2009 22:53:27 +1200
Message-ID: <4A6992A7.1020406@qbik.com>
To: Yves Lafon <ylafon@w3.org>
CC: Henrik Nordstrom <henrik@henriknordstrom.net>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Larry Masinter <LMM@acm.org>

I also would have assumed that MD5 would cover the whole entity.  For 
the reason that it's used as a signature on the entity.

If you get a file in N parts, you can be fairly certain they are all 
parts of the same entity if the C-MD5 is the same for each.

But this doubles up with ETag.

If the MD5 were calculated on only the transferred partial body it would 
need to be calculated each time a part were served.

So I think it comes down to what is the intended purpose of the header 
in the first place.  My assumption would have been to cover potential 
corruption in transit or detect modifications.  But obviously not secure 
since any agent in the chain can recalculate it.  So in the end I feel 
it's of little value which is probably why it's seldom used.

Regards

Adrien


Yves Lafon wrote:
> 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.
>>      *
>>      *
>>
>>
>>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Friday, 24 July 2009 10:50:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT