#1114 "Content-Encoding: gzip" ignored under certain condition

[Lux In Tenebris]

When "Content-Disposition: attachment" is present libcurl will not decode response body.

Example:
$ curl -I http://slivmail.com/messages/original/40098
HTTP/1.1 200 OK
Content-Type: message/rfc822
Connection: keep-alive
Status: 200
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.12
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Disposition: attachment; filename="001f93~2.eml"
Content-Transfer-Encoding: binary
Cache-Control: private
X-UA-Compatible: IE=Edge,chrome=1
X-Request-Id: 9ec69f7ff77b534ff8eff797cb33c5fd
X-Runtime: 0.003493
Date: Wed, 23 May 2012 20:48:46 GMT
X-Rack-Cache: miss
Server: nginx/1.0.15 + Phusion Passenger 3.0.12 (mod_rails/mod_rack)

[Dan Fandrich]

Can you be more specific? How does it not decode the response body? What does it output given the command: curl -v -O --compressed http://slivmail.com/messages/original/40098

[Lux In Tenebris]

curl -v -O --compressed works fine, curl writes uncompressed data

[Lux In Tenebris]

curl 7.25.0 (x86_64-pc-linux-gnu) libcurl/7.25.0

[Dan Fandrich]

So, what's the problem then?

[Lux In Tenebris]

I expect than libcurl will detect the presence of "Content-Encoding: gzip" and uncompress gzip data automatically when writing to a file.

[Dan Fandrich]

And, three comments earlier you said it does. curl will only decompress automatically when given the --compressed option. Otherwise, it returns the raw contents. Have you found documentation that suggests otherwise?

[Daniel Stenberg]

Thanks for reporting this issue and helping us improve curl and libcurl.

We're awaiting feedback in this issue. Due to this, I have set the state of this issue to pending and it will automatically get closed later on unless we get further info.

Please consider answering the outstanding questions or providing the missing info so that we can proceed to resolve this issue!