I have a fresh Drupal 7 install with aggregation of js and css enabled. Litespeed is configured to NOT gzip anything by default, so I am not experiencing double encoding. When Drupal gzips the javascript it is not decoded by Chrome or IE9. It works fine in Firefox and Safari.

I can work around this by disabling gzipping in the settings.php file but this is undesirable as I have don't want to do this for every single site I migrate to the Litespeed server.

Is there anything we can do to ensure that gzipping works with Litespeed?

Note that I have read through #986558 and I believe this to be a separate issue.

#38 drupal-1440534-38-fix-gzip-js-follow-rfc-4329-D8.patch1.19 KBmgifford
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 89,175 pass(es). View
#35 drupal-1440534-35-fix-gzip-js-follow-rfc-4329-D8.patch1.25 KBmikeytown2
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch drupal-1440534-35-fix-gzip-js-follow-rfc-4329-D8.patch. Unable to apply patch. See the log in the details link for more information. View
#7 1440534-Gzipped-javascript-sends-wrong-Content-Type-.patch1.42 KBmstrelan
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,539 pass(es). View
gzipped-headers.png79.29 KBmstrelan
gzipped-js.png180.27 KBmstrelan


mstrelan’s picture

Now that I look at it further I see that the Content-Type header is "application/x-gzip" where it should be "text/javascript". I am able to resolve this by adding Header set Content-Type text/javascript to my .htaccess file beneath "Header append Vary Accept-Encoding" but I'm not sure the best way to apply this only to .js.gz files and not .css.gz. Is this a suitable fix for this or should I be able to force this in Litespeed configuration?

mstrelan’s picture

Title: Aggregated javascript and css does not work with Litespeed webserver and Chrome or IE » Gzipped javascript sends wrong Content-Type response header on Litespeed webserver

Updated title

onyxnz’s picture

Same problem, on Downtownhost.com, with LiteSpeed and gzip.

"by adding Header set Content-Type text/javascript to my .htaccess file beneath "Header append Vary Accept-Encoding"" does not fix for me :(

onyxnz’s picture

Setting the .htaccess to something basic like this:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Removes the server's desire to gzip everything, therefore it is up to Drupal to do it's job....
FIXED for me.

FanisTsiros’s picture

Same here. I am on LightSpeed server also.
#1116416: Use "Header set" instead of "Header append" in .htaccess to avoid double encoding did not solved my original issue: #986558: "Aggregate and compress CSS files" and "Aggregate JavaScript files" in performance settings, is not working.
Deleting (or commenting) this code from .htaccess file:

  <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding

solved my issue.

mstrelan’s picture

You don't want to be deleting that stuff from .htaccess especially if we're trying to get a patch that works for Apache and for LiteSpeed with no configuration changes required.

What works for me is to take this

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding

And replace it with this

    <FilesMatch "(\.js\.gz)$">
      # Serve correct content type.
      Header set Content-Type text/javascript
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding

    <FilesMatch "(\.css\.gz)$">
      # Serve correct content type.
      Header set Content-Type text/css
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding

But there are two reasons I haven't made a patch out of this.

  1. It looks like this should already work with
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    But it doesn't work.

  2. I don't want to double up the FilesMatch rules for css and js separately, but I couldn't get them to work otherwise, therefore I need assistance from a .htaccess guru
  3. .

mstrelan’s picture

Version: 7.x-dev » 8.x-dev
Status: Active » Needs review
1.42 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,539 pass(es). View

Setting to needs review to get more eyes and test bot, and adding a patch.

Kevin Morse’s picture

I'm in the same boat as all of you...

One of my clients insisted on being on their own cloud hosting account and the server they got happens to be running LiteSpeed.

I've tried modifying the .htaccess with your changes and I'm still having no luck. Is there a reason why Aggregate and compress CSS files is working but the Aggregate JavaScript files is not working? That seems very strange to me...

This is the message I'm getting in the Chrome Console:

Resource interpreted as Script but transferred with MIME type application/x-gzip: "http://website.ca/sites/default/files/js/js_xeIhn1zXkFRcOnCdfg5ufsNgSp0K...".

I have also made sure LiteSpeed is not compressing any files on its own.

Also should this issue not be major? I guess LiteSpeed is not very popular.

mstrelan’s picture

It's a shame the .htaccess isn't working for you. IIRC after editing .htaccess you have to manually clear the sites/default/files/js directory and then do a full cache flush.

If that doesn't work just edit settings.php and look for the section on gzip compression, you can set that to FALSE.

Probably not major since Litespeed is not officially supported.

Kevin Morse’s picture

Success! Emptying the js folder did the trick. Thanks very much!

dalberts69’s picture

#6 Worked for me fixing the double gzipping on Eleven2's Litespeed with D7. Thanks for the fix for a frustrating problem!

David Woodberry’s picture

I have been chasing this problem for a week. It was a relief to find this thread.
I am building a new site with D7 on Netfirms server. The trouble only seems to occur with IE. Both FF and Chome work fine. I thought #6 gave me a partial solution but turned out the problem still exists, so have turned off GZIP compression in settings.php

Danny Englander’s picture

I just ran into this same issue with litespeed on WiredTree for a Drupal 7 site. I applied the above patch + clearing cache / JS directory. In the end, I also needed to add this code to the top of my htaccess file:

AddType application/x-gzip .gz .tgz
AddEncoding x-gzip .gz .tgz

I'll probably end up adding this to httpd.conf in order to make it more global in nature. I also was able to leave gzip compression enabled and did not have to uncomment that in settings.php.

My only outstanding issue is that in Chrome Canary, my site is borked as I am getting this error with CSS aggregated files:

Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error. -- but since Canary is still in development, I would expect this type of thing and will look into this. It could be a permissions issue but I doubt it. At any rate, all other browsers work fine including Chrome Production.

Danny Englander’s picture

It turns out that Chrome Production ended up with the very same error as Canary but Firefox, Safari and IE 9 are perfectly fine. When I view any aggregated files, in either version of Chrome, I now get the same Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error.. There seems to be a Google forum post with many different reasons why this is happening but many of them point to the gzip issue but with no real clear solution.

Cottser’s picture

@highrockmedia - It would be great if you could provide the major version numbers of Chrome (i.e. 19 and 21) instead of Production and Canary. This makes it much easier to troubleshoot and reference in the future.

Danny Englander’s picture

@Cottser -- I was actually just going to post an update. It seems that I needed to tweak some settings in the litespeed admin area and that seems to have helped but I still need to do tons more testing to make sure my settings are stable. As of now, my site is working in all browsers. My versions of Chrome are:

Canary: Version 22.0.1186.0 canary
Chrome production: Version 19.0.1084.56

The main setting I changed had to do with Tuning in litespeed, the defaults that I was given by WiredTree were set very low. In addtion, I no longer need to set AddType application/x-gzip .gz .tgz & AddEncoding x-gzip .gz .tgz in .htaccess. It seems that's better handled by litespeed. If anyone is interested, I can provide more info on my litespeed settings. I am cautiously optimistic but as I mentioned, need to do a lot more testing. I am also only working with one Drupal 7 site so far on this server so I probably need to test some different sites that I have. In the end though, I still had to uncomment $conf['js_gzip_compression'] = FALSE; in settings.php. That will probably be the next thing I work on. No matter what I have tried, keeping this commented out simply broke the JS links even with the patch here.

Liliplanet’s picture

Hi highrockmedia,

So wonderful to come upon this thread as on Litespeed at http://www.wiredtree.com and having issues with my feeds due to the same cache issue.

see http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.filmcontact.com%...

Error: Not a gzipped file (Server response declares Content-Encoding: gzip; misconfigured server

When I clear cache all is good for a moment, and then back to error.

Would most appreciate any guidance on how to configure the .htaccess or directly on litespeed on wiredtree.com

Danny Englander’s picture

@Liliplanet -- Just sent you a detailed PM.

Liliplanet’s picture

Thank you all! I've resolved my issue ..

@highrockmedia, sorry did not receive your pm. http://www.WiredTree.com, they really are just absolutely fabulous and found what my problem was:

from Wired Tree:

This is not a LiteSpeed issue. I've switched the server over to running on Apache and the feed validator still displays an error.

I see the following error that occurs when the feed validator loads the http://www.filmcontact.com/daily.xml
PHP Fatal error: Call to undefined function user_access() in /home/public_html/sites/all/modules/user_visits/user_visits.module on line 218

Right now the server is back running on LiteSpeed. What changes did you make to the site before this issue appeared? I've tried Disabling gzip compression in LiteSpeed, and excluding xml files from compression, but that does not seem to have a effect. Thanks.

I disabled the user_visits.module and all was good :)!

2pha’s picture

I am experiencing the same issue on a litespeed server supplied by bitcloud.com.au
#6 worked for me

jasonabc’s picture

I'm running Apache with GZIP enabled and the latest version of D7 (7.17). I have no modules installed except Admin Toolbar and Google Analytics.

I've tried all solutions in this thread and also this one (http://drupal.org/node/986558) to no effect. Whenever I select "Aggregate and compress CSS files" the site totally hoses itself. I just get a black and white site. The CSS files and JS files are all present in the sites/default/files/css & /js folders.

Any ideas gratefully received. We have never run into this issue on our server with Drupal 6...

jasonabc’s picture

Update to #21 - turns out the htaccess file in /sites/default/files/ needed tweaking. CSS and JS aggregation works fine now with default settings.

ambitioustyphoon’s picture

How exactly did you tweak the htaccess file? I'm having the same issue with d7 (7.18) and nothing has worked for me either.

Please let me know what you did so I can try it out!


Danny Englander’s picture

@ambitioustyphoon - Did you try the patch in #7? That relates directly to .htaccess.

ashrafzadeh’s picture

i have this issue too in the litespeed
i solved my own problem by adding
AddType text/javascript .js.gz
at the end of .htaccess file

xenyo’s picture

I think this is an issue that Litespeed should resolve on their end and had a discussion with them to resolve.

Conclusion is that they have located the issue and will be fixing on their next major release.


Maybe can close this issue?

betovarg’s picture

Not yet!

I managed to make it work with #21 on chrome. Does anybody still has that issue on IE? I was trying it on IE 11.
Can someone try on IE and let us know?

mgifford’s picture

GroovyMotion’s picture

Issue summary: View changes

Tried #21 and this one: https://drupal.org/comment/8426719#comment-8426719
Still no luck...in my case it's only the admin toolbar css that breaks once I aggregate the css, .js works.

lancewig’s picture

I wrangled with this after all the solutions. This site is on FatCow (Deplorable hosting for Drupal BTW). They have a setting in the cPanel to cache files. You have to turn all that off first. That all the above solutions work.

Jeff Burnz’s picture

Is anyone hitting this issue running 4.2.10 Ent (x86_64) or indeed is anyone running Version 5.0 Linux (x86_64) 5.0 RC1 Ent?

In this thread its claimed to be fixed in 4.2.6 but then later near the end of the thread it says it wasn't fixed and won't be until 5:

Odd because there actual release log mentions the issue being fixed:

LSWS 4.2.6 11-22-2013 Feature enhancement and minor bug fixes
Fixed bug: Multiple <Files ...> <FilesMatch ...> directives in different .htaccess files along a path were processed in the wrong order.

I'm wanting to move to litespeed shortly but this issue gives me cause for pause, since I actually need these sites to run on both LS and Apache without any changes.

arruk’s picture

#6 worked beautifully for me thank you.

jhedstrom’s picture

The patch in #7 still applies. Are folks here agreed on this approach? It makes sense to me.

mikeytown2’s picture

1.25 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch drupal-1440534-35-fix-gzip-js-follow-rfc-4329-D8.patch. Unable to apply patch. See the log in the details link for more information. View

Status: Needs review » Needs work

The last submitted patch, 35: drupal-1440534-35-fix-gzip-js-follow-rfc-4329-D8.patch, failed testing.

mgifford’s picture

Status: Needs work » Needs review
1.19 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 89,175 pass(es). View


Jeff Burnz’s picture

#38 is not working for me running D8 on Litespeed, CSS and JS appear to be double gzipped, i just commented out the entire mod_headers bit of htaccess and everything seems to work OK, which is probably not right thing to do but I needed it to work right away so I just tried it.

bettledupls’s picture

#6 worked for me.
http://www.whatsmyip.org/http-compression-test/ results improved to -
Uncompressed Page Size: 37.9 KB
Compressed Page Size: 8.7 KB
Savings: 77.2%

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.