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