Gzipped javascript sends wrong Content-Type response header on Litespeed webserver

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 :(

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]
</IfModule>

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

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
    </FilesMatch>
  </IfModule>

solved my issue.

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.

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

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

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

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.

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.

@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.

@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.

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

@Liliplanet -- Just sent you a detailed PM.

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 :)!

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

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...

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 - Did you try the patch in #7? That relates directly to .htaccess.

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

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.

http://www.litespeedtech.com/support/forum/showthread.php?p=77013&posted...

Maybe can close this issue?

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?

7: 1440534-Gzipped-javascript-sends-wrong-Content-Type-.patch queued for re-testing.

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.

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.

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:
http://www.litespeedtech.com/support/forum/threads/drupal-css-js-aggrega...

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.

#6 worked beautifully for me thank you.

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

Merged in #2193333: Follow RFC 4329; use application/javascript instead of text/javascript

I agree with this approach.

reroll

#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.

#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%

Sending to PNMI after 7 years. Can you please verify if this issue is still relevant in 9.5? I see it was originally written for D7 and tons of things have changed since.