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:20:03 +1200
Message-ID: <4C0CF203.9070005@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


On 8/06/2010 1:07 a.m., Daniel Stenberg wrote:
> On Tue, 8 Jun 2010, Adrien de Croy wrote:
>
>> I don't see any point in having an integrity check for a message 
>> containing only a partial range.  Surely you want to accumulate the 
>> entire entity by piecing together all the parts, and then you use the 
>> MD5 to check the total.
>
> Imagine downloading a large file in many small chunks from many 
> different servers.
>
> 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.

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

However isn't this just doing the same job as TCP checksums?  Or are you 
trying to code against corrupt parts coming from a server?

Forgive me but I don't see the point in getting different bits from 
different servers either.

If load is that high on a system that you need to deploy multiple 
servers to satisfy it, you'd be better multiplexing by client, rather 
than by part of an entity.  E.g. spread the load by spreading the 
clients around, rather than spreading entity parts around.

?

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 7 June 2010 13:21:23 GMT

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