- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 08 Jun 2010 01:33:51 +1200
- 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. Adrien 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