Thu, 09 Apr 2026 20:04:46 +0000 https://bugs.horde.org/ticket/7680 gzip/bzip2 upload doubly compressed Reproduce method: - enable "$conf[compress_pages]" in horde config - upload a gzip/bzip2 file in IMP compose window - send that email to yourself - open the email you just sent - download the gzip/bzip2 file to local disk - the file will be compressed TWICE Also, independantly of the setting above, any uploaded .tgz (or .tbz) file cannot be opened in IMP (gives error: "Content type of compressed file: Unknown") If I receive an email that contains a .tgz/tbz file (and that email has not been created with IMP), the attached compressed tar file content can be read within IMP, which leads me to believe there is a link with the upload bug above. Thu, 13 Nov 2008 16:49:39 +0000 https://bugs.horde.org/ticket/7680#t50727 > - the file will be compressed TWICE I can't reproduce this. > Also, independantly of the setting above, any uploaded .tgz (or .tbz) file cannot be > opened in IMP (gives error: "Content type of compressed file: Unknown") This is a limitation of the current MIME lib and can't be fixed until IMP 5. Sun, 16 Nov 2008 22:20:51 +0000 https://bugs.horde.org/ticket/7680#t50779 So, are you saying the problem happens with Horde's MIME library WHEN UPLOADING the gzipped attachment? Otherwise, If you're saying it's only when OPENING the attachment, then it would not explain why this does not happen with an attachment in an email created OUTSIDE of Horde. Sun, 16 Nov 2008 22:44:49 +0000 https://bugs.horde.org/ticket/7680#t50787 No. Individual gzipped files are different from tar files. Sun, 16 Nov 2008 22:49:08 +0000 https://bugs.horde.org/ticket/7680#t50788 > No. Individual gzipped files are different from tar files. OK, but I really meant "tar.gz" files, not just gzipped files. Sun, 16 Nov 2008 23:54:12 +0000 https://bugs.horde.org/ticket/7680#t50789 >> - the file will be compressed TWICE > > I can't reproduce this. I tested again, and it really needs to be a compressed TAR FILE, not just a compressed FILE. Mon, 17 Nov 2008 00:03:40 +0000 https://bugs.horde.org/ticket/7680#t50790 More details for the problem when trying to view the content listing of a tar.gz file within IMP: - a .tar.gz attachment sent using Horde/IMP has a MIME type of "application/x-gzip" - a .tar.gz attachment sent using Thunderbird has a MIME type of "application/x-compressed-tar" Which probably explain the problem (and is probably caused by a limitation in the MIME library, as Chuck already mentioned) Mon, 17 Nov 2008 13:29:50 +0000 https://bugs.horde.org/ticket/7680#t50797 > - a .tar.gz attachment sent using Horde/IMP has a MIME type of > "application/x-gzip" Is this what the browser is sending to Horde/IMP? We use the MIME type information provided to us by the user's browser/OS. Sun, 07 Dec 2008 20:41:12 +0000 https://bugs.horde.org/ticket/7680#t51119 Since I reported this, I re-installed my OS from scratch, and now I don't experience the MIME type discrepancy anymore. So it seems there was something mis-configured with the MIME types in my previous environment. Thanks for this precision, Michael! >> - a .tar.gz attachment sent using Horde/IMP has a MIME type of >> "application/x-gzip" > > Is this what the browser is sending to Horde/IMP? We use the MIME > type information provided to us by the user's browser/OS. Mon, 08 Dec 2008 16:37:01 +0000 https://bugs.horde.org/ticket/7680#t51154 Silly me, I tested with a ".tgz" instead of a ".tar.gz". So the problem is still there, and the "file" command on Linux reports this for a ".tar.gz" file: # file archive.tar.gz archive.tar.gz: gzip compressed data, from Unix, last modified: Mon Dec 8 11:28:54 2008 So it's probably the right behavior. Can someone confirm? > Since I reported this, I re-installed my OS from scratch, and now I > don't experience the MIME type discrepancy anymore. So it seems there > was something mis-configured with the MIME types in my previous > environment. > > Thanks for this precision, Michael! > >>> - a .tar.gz attachment sent using Horde/IMP has a MIME type of >>> "application/x-gzip" >> >> Is this what the browser is sending to Horde/IMP? We use the MIME >> type information provided to us by the user's browser/OS. > Mon, 08 Dec 2008 16:46:59 +0000 https://bugs.horde.org/ticket/7680#t51156 Should have done the same test on the ".tgz" file in the previous post, but here it is: # file archive.tgz archive.tgz: gzip compressed data, from Unix, last modified: Mon Dec 8 11:28:54 2008 Not much of a difference. So where is the MIME type sent to HORDE/IMP coming from? For a ".tgz", IMP receives "application/x-gtar" and for a ".tar.gz", it receives "application/x-gzip" Can someone shed some light on this? Mon, 08 Dec 2008 16:52:19 +0000 https://bugs.horde.org/ticket/7680#t51157 > # file archive.tgz > archive.tgz: gzip compressed data, from Unix, last modified: Mon Dec > 8 11:28:54 2008 And this is correct. This is a gzip'd file. How can 'file' know what is inside the file without uncompressing it? 'file' simply guess what kind of data is in the file. > Not much of a difference. So where is the MIME type sent to HORDE/IMP > coming from? The browser/OS. > For a ".tgz", IMP receives "application/x-gtar" and for a ".tar.gz", > it receives "application/x-gzip" Technically, there is nothing wrong with application/x-gzip. Because that is exactly what the file is. On OS's like windows, there can only be a single extension. So the MIME type 'application/x-gzip' is correct. I realize Thunderbird is sending something different, but I don't necessarily agree with what they are doing (x-compressed-tar does not seem to be used by many people.). So I think the previous analysis in this ticket remains. Tue, 09 Dec 2008 05:03:09 +0000 https://bugs.horde.org/ticket/7680#t51163 This IS a bug. The clue is in the first post: - enable "$conf[compress_pages]" in horde config While page compressing is enabled, Imp _shouldn't_ compress downloaded .gz files. But it does it. Sincerely speaking, I don't know why it doesn't compress the other filetypes, I didn't trace this. But my user complained about 'damaged' *.tar.gz files, so I'm returning to this ticket... Wed, 26 Jan 2011 12:30:26 +0000 https://bugs.horde.org/ticket/7680#t61608 > - enable "$conf[compress_pages]" in horde config I've always had this setting enabled. And I've never seen this problem. > While page compressing is enabled, Imp _shouldn't_ compress > downloaded .gz files. But it does it. Then it is not strictly related to this setting. Because it is completely irrelevant if we compress output to a browser that is already compressed. It may not be efficient, but there's absolutely nothing wrong with doing this. So there must be something different on your server that is causing this issue. And unless you can track it down and tell us exactly what is causing this, there is nothing us developers can do to help with since it is working fine for us. Wed, 26 Jan 2011 18:02:16 +0000 https://bugs.horde.org/ticket/7680#t61611 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)? Fri, 28 Jan 2011 09:46:38 +0000 https://bugs.horde.org/ticket/7680#t61654