Tickets :: Comment on [#7680] gzip/bzip2 upload doubly compressed

* Your Email Address
* Spam protection	Enter the letters below: .___.__ .__.. . __ [__ [__)[__]\ // ` \| \| \| \| \/ \__.
Comment	> I've investigated the issue in detail and here are my findings: > > The problem model (summary): you are using Imp/Horde and a browser. > Horde is configured with $conf[compress_pages] = true. You compose > mail message to yourself. The mail message contains an attachment > which is tar.gz file. You send the message. You download the > attachment from the received message. You find out it doesn't open. > Then you find out it is (gzip) compressed twice (name not changed). > You need to investigate what goes on. > > 1. I used Firefox, MSIE, Chrome and Opera. The attached file was > downloaded incorrectly by Firefox and Chrome. It was downloaded > correctly by MSIE and Opera. So it's really not a Horde bug but > rather a bug (or unpleasant feature) of Firefox or Chrome. > > 2. While downloading, you distinguish MSIE from the other browsers. > You set Content-Type as application/x-msdownload for MSIE while for > other browsers you use Content-Type sent in fact by browser while > uploading file (from mail) (in case content type is not known, you > use application/octet-stream, which is correct). > > 3. Firefox and Chrome send Content-Type: application/gzip while > uploading an attachment. This is incorrect (application/gzip is not > registered by IANA). > > 4. Firefox and Chrome don't want to uncompress server data in order > to get the correct file. They simply write the stream to disk which > is incorrect. In contrary, Opera does it well. > > 5. Firefox and Chrome correctly save the file when HTTP header shows > Content-Type: application/octet-stream (forced by Horde temporary > modification in function downloadHeaders in Browser.php) > > Looks like Firefox and Chrome get *gz file and save it to disk > without further thinking. Opera thinks more and therefore is able to > uncompress data before writing file to disk. > > So, now we know we are doing our job well but some browsers don't > behave well. The question arises, are we doing our best to circumvent > bad browser behavior? Maybe we should always send Content-Type: > application/octet-stream to the browser to make it think and doing > something more (i.e. uncompress compressed chunks)?
Attachment
Watch this ticket

Saved Queries