Open Bug 1269101 Opened 8 years ago Updated 2 years ago

Does not strip gzip transport encoding for gzip downloads

Categories

(Core :: Networking, defect, P3)

45 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mozilla, Unassigned)

Details

(Whiteboard: [necko-backlog])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 2016030500

Steps to reproduce:

Download a file of type application/gzip using transfer encoding gzip and save it to harddisk.

The header of the transfered file:
-------------------------------------------
Cache-Control: private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Connection: Keep-Alive
Content-Disposition: attachment; filename="aol.com!dstoecker.de!1461801600!1461888000.xml.gz"
Content-Encoding: gzip
Content-Length: 1886
Content-Transfer-Encoding: binary
Content-Type: application/gzip
Date: Sat, 30 Apr 2016 12:25:49 GMT
Expires: Sat, 30 Apr 2016 12:25:49 GMT
Keep-Alive: timeout=15, max=100
Last-Modified: Sat, 30 Apr 2016 12:25:49 GMT
Pragma: no-cache
Server: Apache
Strict-Transport-Security: max-age=16070400; includeSubDomains
Vary: Accept-Encoding
x-clacks-overhead: GNU Terry Pratchett
x-dns-prefetch-control: off
-------------------------------------------

This issue occurs when downloading gzip'ed attachments from an Roundcubemail email webinterface, as this enables DEFLATE for all data types (makes no sense for gzip, but as Apache either requires to enable it for all types or specification of each type this is the most sane setting).



Actual results:

The transfer encoded data is saved resulting in double encoded gzip data file on disk with the length of 1886 (see headers).


Expected results:

Only the contents is saved. The file size should be 1863 in the example case.

If I download other files types like application/zip only the contents is saved, as I expect it to be.

There should be no difference in behaviour for gzip-files.
Two notes: 
* Seems to be related to #82319 and #35956. 
* Chromium and Konqueror behave correctly.
Third note:
* For the tests I used a fresh clean Firefox 45.0 openSUSE installation, but version before were affected as well.
Component: Untriaged → Networking
Product: Firefox → Core
So we do not decode gzip if Content-Encoding: gzip but also the file extension is .gz. Check is done at:
http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#897

Only possibility is to start decoding the first gzip and check if inside is again a gz encoded file. In that case we could do the first decoding. If we do a decoding without the check we are going to have a lot of complaints.
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.