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

Re: Content-MD5 and partial responses

From: Jamie Lokier <jamie@shareable.org>
Date: Fri, 24 Jul 2009 15:22:27 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: Yves Lafon <ylafon@w3.org>, Henrik Nordstrom <henrik@henriknordstrom.net>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Larry Masinter <LMM@acm.org>
Message-ID: <20090724142227.GC27755@shareable.org>
Adrien de Croy wrote:
> 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.

I made the same assumption.

> 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.

More importantly, you can compute the MD5 over all the N parts and
compare it against the Content-MD5 value.

That's a kind of end-to-end check.  You can't do that if Content-MD5
applies to the parts individually.

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

Or cached, if the parts have regular sizes.

> 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.

I assumed it was not for security (as it can be changed in transit),
but to detect errors - simple bit corruption in transit or storage, as
well as more complex software errors.

As an end-to-end error checking device, it is better if the
calculation is closer to the origin of the data,

For example, a simple static file server, having Content-MD5 stored
along with the files, perhaps when they are uploaded with PUT, would
be better for "end-to-end" corruption checking than calculating it by
the server responding to GET.

-- Jamie
Received on Friday, 24 July 2009 14:23:11 GMT

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