Re: Hashsum mismatch prevention strategies
[chromium repo issues]
OK, let's see if somebody can check it.
David Kalnischkies wrote:
> On Mon, May 21, 2012 at 9:07 AM, Raphael Geissert <geissert@debian.org>
> wrote:
>> Do you happen to know what are the usual symptons besides the out of
>> order responses?
>
> Anything. I have seen (records of) the B C A thing as well as just
> responding with A and forgetting completely about B and C. The later is
> handled. The more problematic situations are just C as answer and a
> response for A which basically is A, B and C in one batch "nicely"
> combined as three threads seem to be sending a response at once.
Huh.
>> I'm thinking that given that the downloaded data has already been hashed
>> (and hence the mismatch is detected), the method could check if it maches
>> the hash of one of the other requested files.
>> There might be some issues with the cyclic queues that are used, but they
>> shouldn't be too hard to fix.
>>
>> What do you think?
>
> I wonder how opera and now chromium handle this. They don't have hashsums
> and still seem to cope… I know that firefox had some inbuilt
> proxy/webserver blacklist, but not that many debian mirrors will run on
> ISS, i guess…
There's this page about chromium, not sure if they've noticed broken servers
don't comply with their criteria.
http://www.chromium.org/developers/design-documents/network-stack/http-
pipelining
> The problem is that it is not the download method deciding that it has a
> hashsum mismatch but the acquire-item.cc classes which don't know what the
> method has in the pipeline - which could possibly change while we are
> thinking about the mismatch as this runs in different process. There might
> be some way around that with a bit more thinking, but i have the gut
> feeling that this could end-up being quiet a bit of code.
>
>
> The alternative to tell the methods the expected values (hashes, size, …)
> might be nicer. Especially http code could use the size (if known) to
> compare with Content-Length (if send by server) to know before the
> download is completed if the data we got belongs to the file we requested.
> (size mismatches very likely produce hashsum mismatches, too)
Yes, the second approach is what I had in mind. In fact, I thought the
hashes were already being sent. Apparently, I got confused.
The http method could even go as far as checking Digest headers if sent by
the server.
> [Noted both as an idea to test for the next abi break]
Right :-/
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: