Here is an answer that Allan Storm gave someone on StackOverflow (credit goes to him):
When Magento merges any CSS and Javascript files that pass through its rendering system, it will create URLs for those resource like this, and add them to the head of the page
http://magento1point6point1.dev/media/css/a438f0287fdd0c52d9bd196d355a63c3.css
http://magento1point6point1.dev/media/js/0567fb98ebe279ea4faf5acf433fc6a1.js
in turn, this will generate files on the filesystem
media/css/a438f0287fdd0c52d9bd196d355a63c3.css
media/js/0567fb98ebe279ea4faf5acf433fc6a1.js
At this point, Magento is removed from the process almost completely (there's a RewriteCond %{REQUEST_URI} !^/(media|skin|js)/
in .htaccess
to catch non-existant files). It sounds like you have gzip compression setup correctly for other areas of the site. So, however you've configured other folders for gzip compression, configure media/css
and media/js
to do the same.
To read the whole question read: Gzip on merged CSS/JS files in Magento
If this is happening to direct downloads of zip files, it's definitely the rules in the .htaccess or apache config. You'll want to update this section of your .htaccess file:
# Don't compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
with this:
# Don't compress images or zip files
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|zip)$ no-gzip dont-vary
Then make sure that you DO NOT have the blanket SetOutputFilter DEFLATE
rule set and are only using the AddOutputFilterByType
rule to enable the compression. The latter one will turn it on based on mime-type, whereas the first enables it across the board on everything.
After you do this, the server should definitely NOT be double compressing the data when serving files resources where the URL ends in .zip by merit of the mime-type as well as the URI matching the pattern.
If this is happening only on downloads of zip files from purchased downloadable products, and you've done both of the things mentioned above, then you'll need to verify that the Content-Type: application/zip
header is being sent with the download since Magento essentially proxies the content to the browser in a data stream and sets the mime-types itself.
The easiest way to check the headers is to use curl like this:
$ curl -sv http://mage.dev/1.7/downloadable/download/linkSample/link_id/1/ > /dev/null
* About to connect() to mage.dev port 80 (#0)
* Trying 127.0.0.1...
* connected
* Connected to mage.dev (127.0.0.1) port 80 (#0)
> GET /1.7/downloadable/download/linkSample/link_id/1/ HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
> Host: mage.dev
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 08 May 2013 01:55:36 GMT
< Server: Apache/2.2.22 (Unix) PHP/5.3.14 mod_ssl/2.2.22 OpenSSL/0.9.8o
< X-Powered-By: PHP/5.3.14 ZendServer/5.0
< Set-Cookie: frontend=v8qacn7t586ckfljbibnm4ea82; expires=Wed, 08-May-2013 02:55:36 GMT; path=/1.7; domain=mage.dev; HttpOnly
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: must-revalidate, post-check=0, pre-check=0
< Pragma: public
< Content-Length: 905467
< Content-Disposition: inline; filename=lame.zip
< Content-Type: application/zip
<
{ [data not shown]
* Connection #0 to host mage.dev left intact
* Closing connection #0
Best Answer
Make sure
mod_deflate
is on in Apache. You can check by creating aninfo.php
file and callingphpinfo();
. It will output server PHP / Apache specs in the browser. Don't forget to remove it when you're done!Then add the following to your
htaccess
file