[Zgłoszenia #7680] Re: gzip/bzip2 upload doubly compressed

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7680
------------------------------------------------------------------------------
  Zgłoszenia         | 7680
  Updated By         | maciej.uhlig at us.edu.pl
  Podsumowanie       | gzip/bzip2 upload doubly compressed
  Queue              | IMP
  Version            | Git master
  Typ                | Bug
  State              | Not A Bug
  Priorytet          | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


maciej.uhlig at us.edu.pl (2011-01-28 04:46) napisał:

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)?