W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: proposal for issue #178

From: Adrien de Croy <adrien@qbik.com>
Date: Tue, 08 Jun 2010 01:33:51 +1200
Message-ID: <4C0CF53F.6080003@qbik.com>
To: Daniel Stenberg <daniel@haxx.se>
CC: Yves Lafon <ylafon@w3.org>, Henrik Nordström <henrik@henriknordstrom.net>, ietf-http-wg@w3.org

when serving a part of an entity, having to provide an MD5 for that 
part, the server would just calculate it at the time it served it, in 
which case if the file is corrupt, the MD5 won't help you.

Otherwise the server would have to pre-calculate a bunch of MD5s of 
different part sizes and different parts at the time it knew the parts 
were not corrupted...

In which case the server could just check the MD5 itself, and return an 
error if it couldn't serve an uncorrupted file... so this leans towards 
having the MD5 on the total entity.


On 8/06/2010 1:24 a.m., Daniel Stenberg wrote:
> On Tue, 8 Jun 2010, Adrien de Croy wrote:
>>> In the end, you might sit there with a huge file with a bad checksum 
>>> without being able to pinpoint the single small chunk that had the 
>>> error. So now you need to redownload the whole thing again, instead 
>>> of just regetting the small chunk that contained the error.
>> I didn't think that was really supported by HTTP, since you can't 
>> know without some meta information that parts from different servers 
>> belong to the same entity.
> Well, that meta information can still exist. See RFC5854 for inspiration!
>> in which case it's an extension, in which case may as well add a new 
>> header to explicitly cover the part entity.  E.g. Content-Part-MD5 or 
>> something. And leave Content-MD5 as it is (could use both).
> Yes it can, I was not really advocating for any particular header. I 
> was merely suggesting that there are use-cases where getting a 
> checksum on a range can be useful.

Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 7 June 2010 13:35:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC