(Imported from Trac #622, reported by guest on 2010-01-03)
As can be seen here,
> HEAD http://hackage.haskell.org/packages/00-index.tar.gz
This breaks with at least on virus scanning proxy, namely AvkHttp (of InternetSecurity by G DATA):
> cabal update -v3
Downloading the latest package list from hackage.haskell.org
GET /packages/archive/00-index.tar.gz HTTP/1.1
Creating new connection to hackage.haskell.org
HTTP/1.1 200 OK
Date: Sun, 03 Jan 2010 09:52:53 GMT
Server: Apache/2.2.3 (Debian)
Last-Modified: Sun, 03 Jan 2010 09:38:56 GMT
Downloaded to /home/nils/.cabal/packages/hackage.haskell.org/00-index.tar.gz
cabal: Codec.Compression.Zlib: incorrect header check
https://bugs.launchpad.net/malone/+bug/173096 describes a similar problem, and has some discussion about why using Content-Encoding in this way is useful in some cases but hurtful in others.
(Imported comment by guest on 2010-01-03)
After reading RFC 2616, it becomes clear that the proxy is buggy.
A transparent proxy (and a virus checker ought to be one) is not allowed to change Content-Encoding. Even for non-transparent proxies, http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.5.2 says this about Content-Encoding, Content-Range and Content-Type:
A non-transparent proxy MAY modify or add these fields to a message that does not include no-transform, but if it does so, it MUST add a Warning 214 (Transformation applied) if one does not already appear in the message (see section 14.46).
There's no such warning in the reply above.
I still think the headers should be different, but it doesn't seem to be a bug on the hackage side. Perhaps adding a Cache-Control: no-transform header to the HTTP requests from cabal-install would be a good idea as well.
(Imported comment by @dcoutts on 2010-01-03)
So it's clear that the Hackage server is sending the correct headers. So I think the solution is that cabal-install should be slightly smarter and look at the Content-Type and Content-Encoding. The behaviour should be:
Content-Type: | Content-Encoding | Action
application/x-gzip | (none) | decompress
application/x-tar | x-gzip | decompress
application/x-tar | (none) | none
_ | _ | error
(Imported comment by finlay on 2010-01-06)
Replying to @dcoutts:
In the second case, can cabal-install be more tolerant to broken proxies (#686) and try decompressing, and on failure, check if already has been decompressed ?
(Imported comment by adept on 2010-10-20)
Just for reference: this behavior could be recreated locally on linux box by installing "ziproxy" and specifying "MaxSize? = 0" and "Gzip = false" in its config.
(Imported comment by @dcoutts on 2010-10-27)
Wed Oct 27 10:50:34 BST 2010 Duncan Coutts <firstname.lastname@example.org>
Given that there is no activity since 2010, perhaps this is resolved? At any rate, I propose closing due to inactivity. Please re-open or create a new issue if this is still occurring.