6.0.0-git
2019-04-24

[#11180] gzip attachments get double gzip on download
Summary gzip attachments get double gzip on download
Queue IMP
Queue Version Git master
Type Bug
State Not A Bug
Priority 2. Medium
Owners
Requester patrickdk (at) patrickdk (dot) com
Created 2012-05-08 (2542 days ago)
Due
Updated 2012-05-10 (2540 days ago)
Assigned 2012-05-09 (2541 days ago)
Resolved 2012-05-09 (2541 days ago)
Milestone
Patch No

History
2012-05-10 00:43:52 patrickdk (at) patrickdk (dot) com Comment #8 Reply to this comment
The data is not compressed a 3rd time, and I'm using lighttpd without 
the compression module (the compression module doesn't support 
compression of dynamic content, only static files anyways)

a tcpdump of the stream shows double compression:

HTTP/1.1 200 OK
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: application/x-gzip
Content-Disposition: attachment; filename="test1.tar.gz"
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
Date: Wed, 09 May 2012 22:01:17 GMT
Server: lighttpd/1.4.30

fff8
....................X.O..test1.tar...y<.}.?.OI.$d..(E.b.:mHN..b*.c".

compared to the real file:

_KHHOX)O@Ctest1.tar@l}y<T}{?LOIR$dO)(ERbI:mH

If I disable compress in horde config, all is fine, and everything 
works, but all pages are uncompressed, html/js/css/...

The same issue on my apache config, if I disable horde compression, 
and only use the deflate module, I get compression, plus downloads of 
the gzip attachment work properly.

Seems to be this firefox bug, I suppose:
https://bugzilla.mozilla.org/show_bug.cgi?id=610679

As long as content-encoding isn't in use, on gzip'd files, it's not an 
issue, and since mod_deflate isn't compressing already gzip content, 
it works.

Also while looking at a workaround for this, I found that the 
imp/view.php appInit nocompress option isn't used, cause the 
services/download/index.php overrides it.

I added:
'nocompress' => ((Horde_Util::getFormData('actionID') == 
'download_all') || Horde_Util::getFormData('zip') 
||(substr_compare(Horde_Util::getFormData('fn'), 'gz', -2, 2,true) 
==0)),
do services/download/index.php appInit as a simple workaround.

The other workaround would be to completely disable hordes buildin 
compression, and use browser based compression instead, but lighttpd 
currently doesn't support that for php.

2012-05-09 19:23:35 Michael Slusarz Comment #7
State ⇒ Not A Bug
Reply to this comment
I agree that it is the browsers job, just can't figure out why though.

I mean, I can't believe all my browsers have the exact same bug, in 
firefox, opera, chrome.
Which means it is probably a server-side (i.e. HTTP server issue).  My 
guess is that you have both Horde/PHP configured to gzip data and your 
server configured to gzip data.  So when received by the browser, it 
is actually compressed 3 times - the browser removes one layer and you 
are left with double compression.

This is a config issue however and should be discussed on a mailing 
list instead of the bug tracker.
2012-05-09 18:59:29 patrickdk (at) patrickdk (dot) com Comment #6 Reply to this comment
I agree that it is the browsers job, just can't figure out why though.

I mean, I can't believe all my browsers have the exact same bug, in 
firefox, opera, chrome.

I've had 3 other users confirm this for me. And on two totally 
different horde4 installs.

Hmm, very odd, I don't have this issue with IE 8,9
I do have it with firefox/opera/chrome on ubuntu or windows 7

2012-05-09 17:25:26 Michael Slusarz Comment #5 Reply to this comment
I can't reproduce either.  Which makes sense - as Jan says, it is the 
*browser's* responsibility to remove one level of compression before 
the data is presented to the user.
2012-05-09 14:12:39 Jan Schneider Comment #4 Reply to this comment
Cannot reproduce. Beside that, it's the browser's job to decode 
Content-Encoding before saving the file.
2012-05-09 14:02:23 patrickdk (at) patrickdk (dot) com Comment #3 Reply to this comment
And what's wrong with that?
you have to ungzip before you can ungzip then untar the archive.

:/tmp# file test1.tar.gz
test1.tar.gz: gzip compressed data, from Unix

:/tmp# gunzip test1.tar.gz

:/tmp# file test1.tar
test1.tar: gzip compressed data, was "test1.tar", from Unix, last 
modified: Tue May  8 13:33:03 2012

2012-05-09 13:57:04 Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
And what's wrong with that?
2012-05-08 21:27:52 patrickdk (at) patrickdk (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ gzip attachments get double gzip on download
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
Reply to this comment
Receiving an email with a gzip attachment, gets an extra gzip later 
added to it when downloading the file.
I have confirmed this using firefox/opera/chrome browsers, all latest 
stable releases.
I have also confirmed this using normal apache 2.2 config, and with 
lighttpd (no compression enabled on lighttpd)

Response Headers
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:Keep-Alive
Content-Disposition:attachment; filename="test1.tar.gz"
Content-Encoding:gzip
Content-Type:application/x-gzip
Date:Tue, 08 May 2012 21:12:22 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=15, max=100
Pragma:no-cache
Server:Apache/2.2.14
Transfer-Encoding:chunked
Vary:Accept-Encoding

Saved Queries