The only browser which doesn't have this problem that I found is NetSurf (tested on version 2.8).
Even wget has the problem, in a sense (see ). Chromium has it (see ), Konqueror 4.7.4, Opera 11.62, Safari 5.1.4 and Internet Explorer 8. I hit this bug when downloading from my local httpd, Apache 2.2.22 on Debian testing, with a highly stock configuration.Īmazingly, all major browsers have the same problem.
#FIREFOX 40.0.3 FINAL FILEHIPPO DOWNLOAD#
When I download it and hit this bug, the double-gzipped version I get has MD5 sum 4b978d76df448f894fcf427f86d74674. The file I use to test is and has MD5 sum 3d9b4fbacb5c1c4b6fc6930ad02abd28. I was able to reproduce this using my system as the server and a random. I hit what I think is this bug on with update_. I can do this in Debian by addingĪddOutputFilterByType DEFLATE application/x-tar
I can reproduce using Iceweasel 10 with Matej's file by renaming it to and configuring Apache to compress tarballs. So I don't think you're seeing "HTTP headers munging based on User-Agent", but rather a difference in replies because Firefox sends Accept-Encoding while cURL does not, unless invoked with -compressed. That extension allows copy-pasting.Īlso, cURL does not request compressed replies by default. Matej, note that you can use mozilla-livehttpheaders to get HTTP headers. Is anyone able to reproduce this with a current Firefox? And if so, can you provide a new test URL? It looks like Apache was fixed to avoid compressing tgz-s, since they're already compressed, so Firefox may still be buggy, but Apache no longer exposes the bug. I also tried putting the file on my local Apache 2.2.22 and couldn't reproduce, but mine is also not (re-)compressing the file, even though mod_deflate is enabled. It seems the server has changed though, it's now running Apache 2.2.15, and no longer compresses the (already compressed) file. However, that is not a tarball and I can't reproduce your specific problem with Iceweasel 10.0.3.
#FIREFOX 40.0.3 FINAL FILEHIPPO WINDOWS#
And I haven't noticed this on Windows or 32bit Linux (right now I'm on a new amd64 box). I see no reason why FF 5 behaves like this. It's possible to set the filename with content-disposition header, but the URLs remain ugly. In this case it's driven just by mime-type, because the filename is not part of the URL. Test.tgz + application/octet-stream => OK So there's no way to have 'nice' URLs and correct behavior. Test.tgz + application/gzip => gzipped (shouldn't be) Test.tgz + application/octet-stream => gzipped (shouldn't be) Test.bin + application/gzip => gzipped (shouldn't be) Test.bin + application/octet-stream => OK It is not triggered just by a mime-type, a filename matters too, depending on the URL format. I do have exactly the same problem in FF 5.0, it's extremely and I have found no reasonable workaround.
The file should stay in the same URL for some time, so there shouldn't be a problem to reproduce this at will. Why shouldn't Firefox just download the file and doesn't let it be (especially considering there is no Content-Encoding header whatsoever)? % Total % Received % Xferd Average Speed Time Time Time Currentġ00 28 0 0 8929 0 -:-:-:-:-:-:- 20860įmci-final.tgz: gzip compressed data, from Unix, last modified: Mon Nov 8 19:44:39 2010 When downloading with curl I get correctly once gzipped tarball as expected: rw-rw-r- rrakus/rrakus 2605 19:34 fmci-final/fmci-server.c rw-rw-r- rrakus/rrakus 1954 19:32 fmci-final/fmci-client.c
rw-rw-r- rrakus/rrakus 326 19:20 fmci-final/fmci.xml rw-rw-r- rrakus/rrakus 1443 18:40 fmci-final/Makefile rw-rw-r- rrakus/rrakus 1602 19:21 fmci-final/fmci-server.h Jakoubek:~ $ mv fmci-final.tar ĭrwxrwxr-x rrakus/rrakus 0 19:44 fmci-final/ 1 matej matej 2,8K 9. lis 17.19 fmci-final.tarįmci-final.tar: gzip compressed data, from Unix, last modified: Mon Nov 8 19:44:39 2010 1 matej matej 2,8K 9. lis 17.19 fmci-final.tgzįmci-final.tgz: gzip compressed data, from Unix When I download file with Firefox I get double gzipped file:
0 kommentar(er)
