When wget and curl know better than you do: unwanted automatic decompression

[Mojca Miklavec]

On Wed, Jan 21, 2015 at 12:01 PM, René J.V. wrote:
> On Wednesday January 21 2015 11:31:09 Mojca Miklavec wrote:
>
>>On Mac (getting decompressed file, inside the firewall):
>>
>>HTTP/1.1 200 OK
>>Via: 1.1 ZID
>>Content-Length: 31261184
>>Content-Type: application/x-gzip
>>ETag: "1f9ae58-5ae0fc-50a6d6282b700"
>
>>I think I understand now. It must be our "smart" firewall (running on
>>Windows 2003!) that's modifying files. I'll talk to our sysadmin (who
>>will most likely have no clue how to solve the problem).
>
> Yikes, typical MS dumbness? Not only doing something you didn't ask for, but also in a half-baked way (decompression but not changing the MIME type nor the hash) ...
>
> You can't get the tarball via https or ftp, by chance (if the firewall doesn't meddle with these too)?

How can I fetch this file from https/ftp? I ended up copying the file
with scp from another server, so I have the file now.

Also, if I copy the file to my own server and try to get it from
there, it gets through compressed:

HTTP/1.1 200 OK
Via: 1.1 ZID
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
Content-Length: 5955836
Date: Wed, 21 Jan 2015 12:17:19 GMT
Age: 0
Content-Type: application/x-gzip
ETag: "5ae0fc-50d282ec8fe85"
Server: Apache
Accept-Ranges: bytes
Last-Modified: Wed, 21 Jan 2015 11:51:58 GMT

It's weird that I haven't been bitten by this issue more often. I have
been regularly working on this network for at least a year.

(I have been bitter by other issues though, like inability to run
rsync / "port selfupdate", because opening the corresponding port in
the firewall for a protocol that our sysadmin has never heard of would
pose a threat for security and integrity of the entire network.)

Mojca