pre-compressed gzip break on chrome, why?

Question

I serve pre-compressed CSS and JS files on my site, and IE6-8 and FF is working perfectly with my .htaccess file.

# Compressed files
RewriteCond %{HTTP:Accept-Encoding} .*gzip.*
AddEncoding x-gzip .gz
AddType application/x-javascript .gz
AddType text/css .gz

I call the files with the .gz extension already [example]:

<link rel="stylesheet" type="text/css" media="all" href="css/layout.css.gz" />

So why is this breaks in google Chrome?

Thanks.

Answer 1

Download Fiddler and look at the raw response headers to see what the server is sending back for that particular request.

FYI, Fiddler is a client side proxy that filters your browser requests through. Super informative when dealing with these kind of issues.

-- Update

Upon further investigation, it doesn't appear that your RewriteCond is actually doing what you think it is doing. According to the Documentation, the RewriteCond directive is only used in conjunction with a RewriteRule.

Answer 2

Our .htaccess file (we have .jsz files with compressed javascript, and Chrome handles them fine):

AddEncoding gzip .jsz
AddType text/javascript .jsz

Answer 3

Safari (and Google Chrome) don`t works with compressed file if they extension is .gz

To support gzip archives on Safari and Chrome, copy and compress .css and .js files into gzip and rename they extension a .gz on the .jgz (for example: before - one file style.css into directory after - two files, style.css and style.css.jgz into directory )

And added this code into your .htaccess file:

AddEncoding gzip .jgz
RewriteCond %{HTTP:Accept-encoding} gzip
# RewriteCond %{HTTP_USER_AGENT} !Safari
RewriteCond %{HTTP_USER_AGENT} !Konqueror
RewriteCond %{REQUEST_FILENAME}.jgz -f
RewriteRule ^(.*)$ $1.jgz [QSA,L]

<IfModule mod_headers.c>
    Header append Vary User-Agent
    <FilesMatch .*\.js.jgz$>
    ForceType text/javascript
    Header append Vary Accept-Encoding
    Header set Content-Encoding: gzip
    Header set Cache-control: private
    </FilesMatch>
    <FilesMatch .*\.css.jgz$>
    ForceType text/css
    Header append Vary Accept-Encoding  
    Header set Content-Encoding: gzip
    Header set Cache-control: private
    </FilesMatch>
</IfModule>

For example megaburg.ru Tested - is working with Safari, Chrome, Opera and Firefox 8)

Answer 4

1. You must use the Content-Encoding: gzip response header.
2. You must only return GZIP compressed content when the client's Accept-Encoding header allows GZIP.

Answer 5

I answered a similar question with a much more conservative matching rule for when to Gzip:

Safari, Chrome, and IE6 all have problems with Gzipped downloads. Also, Apache will do the gzip compression for you, there is no need to manually gzip files. Try this snippet:

# This uses mod_deflate, which is pretty standard on Apache 2.  Loading
# mod_deflate looks like this:
#
#   LoadModule deflate_module modules/mod_deflate.so
#
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \\bMSIE !no-gzip !gzip-only-text/html

See the original post: How can I make my .htaccess file allow Safari & other browsers to open GZIP?

Answer 6

You would just need to set the Content-Encoding header field to tell the client, that the response data is encoded with gzip:

<FilesMatch "\.gz$">
    Header set Content-Encoding gzip
</FilesMatch>

But unfortunatly Apache doesn’t allow to set that header field. Instead Content-Encoding will become X-Content-Encoding.

Answer 7

Google Chrome (and Apple Safari) do not support gzip compressed CSS and JavaScript. Certain IE6 versions also have problems. They do support gzip compressed HTML documents, but not CSS and JavaScript.