Drupal CSS & JS Aggregation problem

Xenyo · Jan 18, 2014

When Drupal sites turn on the Core CSS or JS Aggregation options, they break.

think we have narrowed it down to:

Code:

Header set Content-Encoding gzip

from the Drupal core htaccess file of

Code:

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

Any ideas?

Xenyo · Jan 18, 2014

Seems a similar problem to http://www.litespeedtech.com/support/forum/showthread.php?t=5577 .

As we have quite a few sites on the server, I am looking for a way to solve the issue without changing every htaccess file.

Any thoughts would be appreciated.

NiteWave · Jan 19, 2014

I did unit tests for .css, it looks above rewriterule works.

firstly let's check the response header for .css

can you post the response headers for a .css file which is working under apache but not under litespeed?
#curl -I xxx.com/a.css

Xenyo · Jan 19, 2014

multiple Accept-Encoding in response headers

Hi,
I made a change to my setup and introduced a port offset so now Litespeed is on port 2080 and Apache is on port 80.

When I request the same css from port 2080 the headers I get back (using live http headers plugin in Firefox) are these:

When I request the same css at port 80 the Apache server returns these headers:

The problem is related to douple gzip whereby content which has already been compressed by drupal (using the Aggregate and compress css option) is again compressed by litespeed and an additional Accept-Encoding gzip header inserted into the payload.

Curl works fine with this as it is built to strip multiple copies of the same header. However Chrome, Firefox and practically any other browser fail to unerstand a Accept-Encoding response that reads "gzip,gzip".

What would help is if Litespeed could somehow not try to slap on the Accept-Encoding gzip on top of already compressed content. In this case Drupal sends a css.gz file for delivery to the browser but Litespeed tries to recompress it. Firefox comes back with this additional message:

Content Encoding Error

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

Click to expand...

NiteWave · Jan 19, 2014

base on the headers you get, I think if comment out
<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>

.css will work with both apache and litespeed.

can you confirm or correct this.

Xenyo · Jan 19, 2014

NiteWave said:

That works perfectly fine however it is something I already know, as I pointed out in my original message.

In fact just commenting out
Header set Content-Encoding gzip
is good enough to make it work with Litespeed.

However the problem is slightly more involved. This is part of the default .htaccess from Drupal. I have over 200 drupal powered websites which I want to put on litespeed servers over the next few months. Asking each of these clients who are migrating from Apache to edit their .htaccess file so they can start hosting on my new webhosting platform is kind of not very smooth. I anticipate problems with Wordpress (super cache) as well in future. The point being that this is an issue related to litespeed sending a bad header to the browser and should ideally be looked at by Litespeed.

Agreed that it maybe bad programming on the end of Drupal, WP Supercache and maybe a few other scripts out there that employ pre-compression. However if Litespeed can sanitize the header before sending to the end user it might be a good way to handle things and it would allow me to use Litespeed instead of Apache (which is actually not a bad proposition in terms of speed when tuned properly and it handles coding issues like this one pretty well). Think about it, if we could get traction on a mod so that Litespeed sanitizes the header before delivery that would help hosts like us to decide on using LSWS versus staying with Apache.

NiteWave · Jan 19, 2014

Thanks, both for technical and marketing info you've addressed.

technical side,

I agree with you too.

at present,
Header set ....
not strong yet in lsws and we actually already put it in todo list in next release.
your message may increase the priority of this feature, I believe.

Xenyo · Jan 19, 2014

Thx Nitewave,

Any idea of approx timeframe?

mistwang · Jan 19, 2014

Are you using the latest 4.2.6 package, if not sure, please do

/usr/local/lsws/admin/misc/lsup.sh -f -v 4.2.6

It should handle drupal's default .htaccess just fine. LSWS wont compress it again when serve any ".gz" files from drupal's cache.

So, the header problem should only happen if there are multiple .htaccess along the path containing multiple copies of

Please PM me a temp root password if the latest 4.2.6 build did not fix it, if you do not mind.

Xenyo · Jan 20, 2014

Hi Mist,

We are already using Litespeed Web Server Enterprise v4.2.6

It actually a commonly known problem that prevents many Drupal installations as documented on https://drupal.org/node/1440534 . For single or few installations, the chosen method is to disable the Drupal gzip. However, I think it would be a good idea for Litespeed to resolve the issue out the box to make Litespeed more user friendly for Drupal websites or shared hosting.

NiteWave · Jan 20, 2014

Hi, please do force-reinstall 4.2.6 by
/usr/local/lsws/admin/misc/lsup.sh -f -v 4.2.6
or
lsws web admin -> Actions -> Version Manager -> 4.2.6: Force Reinstall

then test again. it may solve your issue already. if not, report back and I'll install a drupal in our lab.

Xenyo · Jan 20, 2014

Nitewave,

We already did the force reinstall to 4.2.6 via lsws web admin -> Actions -> Version Manager -> 4.2.6: Force Reinstall after your initial response.

mistwang · Jan 20, 2014

Possible to get a temp root access to check the setup quickly.

Xenyo · Jan 20, 2014

Mist,

Not really I am afraid as the server already has client sites on it which we cannot provide you access to.

Just install a Drupal installation on any LS server with compression on or off, you will see.

NiteWave · Jan 20, 2014

I just installed drupal 7.26 with lsws 4.2.6 (https://drupal.org/project/drupal)
enabled
Aggregate and compress CSS files.
Aggregate JavaScript files.

no issue, working fine. however this is the minimal installation. only 1 page: the home page.

what's your drupal distribution? If can reproduce the issue in our lab, trouble-shooting will be much easier.

I think you can install a minimal drupal under a test directory, to see if this issue exists.

Xenyo · Jan 20, 2014

Hi,

Do you mind PMing or sending me link to your Drupal site?

Maybe with the Drupal admin creds.

We tried on multiple sites, so either our LS setting issue or something particular about your installation. The fact that other Drupal sites have this issue (a Google search will bring up multiple issues on this topic) would indicate that this problem either;

1. LS issue but applies to Drupal sites configured a certain way or with certain commonly used Drupal modules installed.
2. LS issue but somehow your particular Drupal Core install is not affected: Cached?
3. Our server issue (Although this would also apply to the other issues noted elsewhere and hence a commonly reproduced issue.)

NiteWave · Jan 20, 2014

Sorry, not possible. the site is installed in LAN
the URL is http://192.168.0.101:8088/drupal/

Xenyo · Jan 20, 2014

Thx Nitewave,

Ok, we'll see if we get any spare time during these next couple of days. However to be honest, for this server I have already given instruction to switched back to Apache and optimized as we had spent to long trying to figure this issue out last week.

Ideally, we would liked to have gone with LS and infact already paid for the Enterprise plan before we hit this problem. My concern is that there maybe more of these little issues later which would not be worth the benefits that LS brings.

Maybe later we will revisit LS again but in the meantime, it would be great if we could help you resolve this issue that enable Drupal use and if you need any Drupal assistance from us, feel free to ask. Also i presume you ahve cleared cache on your installation.

NiteWave · Jan 21, 2014

today I did tests again

first tested on an old 4.2.6 release (dated Nov 24, 2013)

while the homepage is ok, but in chome developer's console(press F12), .js shows content-type is application/gzip, not application/javascript.(.css is right -- text/css). i.e., force content-type
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]
not work while
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
working.

then I did force-reinstall 4.2.6 release(dated Jan 21, 2014)
.js 's content-type is correct -- text/javascript

so I'd think this bug maybe already fixed by latest 4.2.6

if you did force-reinstall after mistwang's first response, then it's already the latest one(and the issue may be fixed in this release update). if you did it after my initial response, then that's not the latest one

Xenyo · Jan 21, 2014

Thx,

So you mean you mean there are 2 (or more versions) of 4.2.6 and we should try again to Force reinstall? I am willing to ask my guy to do this but wanted to confirm that there is a difference to reinstall now from the force reinstall we did a couple of days ago.

Drupal CSS & JS Aggregation problem

Member

Member

Administrator

Member

Administrator

Member

Administrator

Member

LiteSpeed Staff

Member

Administrator

Member

LiteSpeed Staff

Member

Administrator

Member

Administrator

Member

Administrator

Member