Comment 7 for bug 996151

> A much better suggestion would be to detect a proxy during install (most proxies add headers to their reply) and drop a pipeline depth config into /etc/apt/apt.conf.d/ ... Or perhaps not pipeline the first request and look for a proxy in the reply, then turn it on.

Its a bit unfair to disable it for all proxies (and as said I am not even sure squid is still fully buggy) - and after all S3 and the other "dumb storage" entities which triggered this are not proxies, so we would gain nothing – and they seem to be in no way interested to follow a standard because they are "the cloud" and "the cloud rulez": "Hey, there is a + in the URI, that must be a space!" …

Looking just at the first response from the server is not going to work as we are frequently lucky enough to get the expected response just by chance. I can find frequent reports that reducing the Pipeline-Depth to 2 makes it work "all the time" (which is not too surprising, but still fails once in a blue moon).

I guess our only option is to check the hashsum of the file in the methods already (we calculate them there, so we "just" have to tell them what to expect), so that on a mismatch we can see if another file we requested in the pipeline matches the hashsum and if so do a data shuffle and disable pipelining for this server in this run (in the hope that it will be fixed soon - or in fear that a different one will answer our request next time).

That is quiet a bit of work though and not only on the code, but also on the test front – and has very ugly corner cases (partial downloads, …) just to work around the problems in "the cloud" … (I should just have grown some balls and tell the world "<censored>!! Fix Pipelining <censored>!" I guess, but I am so weak, I even censor myself …)