Drupal CSS & JS Aggregation problem

#21
yes. and this is the purpose of force-reinstall -- version number is same, but binary has little difference because the new version may have fixed one or more small bugs in rare cases(for example issue discussed in this thread)
 
#22
yes. and this is the purpose of force-reinstall -- version number is same, but binary has little difference because the new version may have fixed one or more small bugs in rare cases(for example issue discussed in this thread)
Hi NiteWave,
A force install was done around 24 hours back and again now. After the reinstall the graceful restart was done automatically and just to be sure I actually did a manual restart as well using /etc/init.d/lsws stop followed by start. So litespeed is defintely running the new 4.2.6. I also checked to make sure the binary is updated.

[root@armadillo public_html]# ls -larth /usr/local/lsws/bin/lshttpd
lrwxrwxrwx 1 root apache 15 Jan 21 15:17 /usr/local/lsws/bin/lshttpd -> ./lshttpd.4.2.6
[root@armadillo public_html]# date
Tue Jan 21 15:19:24 HKT 2014
[root@armadillo public_html]#
After the force upgrade I removed all cache from my drupal install using the webinterface as well as running this command:

rm -rf sites/default/files/css/* sites/default/files/js/*
This ensures there are no stale copies of the aggregated/compressed css/js cached on the server.

Next I accessed the site and it was working perfectly fine. After this I accessed the site on port 2080 where litespeed is running and there is no styling information available.

I did a view source and looked for a css included in the code. Tried loading the css and got the following response headers in Firefox:

HTTP/1.1 200 OK
Content-Encoding: gzip, gzip
Vary: Accept-Encoding, Accept-Encoding
Date: Tue, 21 Jan 2014 07:24:52 GMT
Server: LiteSpeed
Accept-Ranges: bytes
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Last-Modified: Tue, 21 Jan 2014 07:18:00 GMT
Content-Type: text/css
Content-Length: 594
Cache-Control: max-age=2592000
Expires: Thu, 20 Feb 2014 07:24:52 GMT
In Chrome the message I get is:
The web page at http://www.XXXXXXXX:2080/sites/default/files/css/css_5XB5aQOGzDUVxnwtHDXg0AJDjmjZbe2Sh1K2BEkR5cM.css might be temporarily down or it may have moved permanently to a new web address.
Error code: ERR_CONTENT_DECODING_FAILED
The headers in Chrome look like this:
Accept-Ranges:bytes
Cache-Control:max-age=2592000
Connection:Keep-Alive
Content-Encoding:gzip
Content-Encoding:gzip
Content-Length:2198
Content-Type:text/css
Date:Tue, 21 Jan 2014 07:30:09 GMT
Expires:Thu, 20 Feb 2014 07:30:09 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Tue, 21 Jan 2014 07:18:00 GMT
Server:LiteSpeed
Vary:Accept-Encoding
Vary:Accept-Encoding
As far as I see it the new Litespeed has not made a difference. If I comment out just one line
Header append Content-Encoding gzip
from .htaccess it starts working normally. So effectively Litespeed does not work for Drupal out of the box for us. I have tried LiteSpeed on two different servers one with and one without DirectAdmin and both throw the same issues.

If you give me a server (maybe one of the smallest droplets on DigitalOcean) I could make the time and setup the system for you the way I'm building it and deploy one of my sites there to demonstrate the problem. I wouldn't charge for this assistance if it helps, just get me a test server.
 
#23
today I did more tests on my local drupal core installation.

get a surprising result (need further confirmation)
following rules in drupal root's .htaccess
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>
actually not work, or dummy(both apache and lsws). if move to sites/default/files/css/.htaccess and sites/default/files/js/.htaccess, works.

if this is true, maybe a big news ? :)
 
#24
When you say, not work ... which part do you mean?

I mean obviously ;

Header set Content-Encoding gzip

is working hence the problem right?
 
#25
one major purpose of
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
Header set Content-Encoding gzip
Header append Vary Accept-Encoding
</FilesMatch>
is:
when request http://.../sites/default/files/css/test.css
if sites/default/files/css/test.css.gz exists, then web server send .../test.css.gz directly back to browser.

my test result:
when request http://.../sites/default/files/css/test.css directly,
browser get "404 Not Found". that is to say, above rules under drupal root not work as expected, but put those rules in sites/default/files/css/.htaccess, will work as expected.

why those rules not work but page still display correctly, I think because of
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]
i.e., pass to index.php to process.
as result, .css files are served as dynamic page(php), not static page.
we know static page are much efficient than dynamic page.

to verify, just remove above rules from drupal root/.htaccess, the site should still display correctly. then add to files/css/.htaccess, to archive the initial goal.
(I did tests on my minimal drupal installation and ok)

of course, the issue discussed in this thread "why work under apache but not under litespeed", not clear yet, but there is progress toward it.
 

mistwang

LiteSpeed Staff
#26
When you say, not work ... which part do you mean?

I mean obviously ;

Header set Content-Encoding gzip

is working hence the problem right?
I think I knew what happened.

along the path to the target CSS/JS file, there are multiple .htaccess file containing "Header set Content-Encoding gzip", so that header was added multiple times, LSWS treat "Header set ..." the same way as "Header append ...".

this issue was not fixed in the latest 4.2.6, but will be fixed in 5.0 release.
 
#27
Mist,

Yes there are multiple .htaccess .

Good to hear you have located the issue and thanks for the effort.

Any approx. timeframe on 5.0 ?
 
#30
Hi NiteWave,
A force install was done around 24 hours back and again now. After the reinstall the graceful restart was done automatically and just to be sure I actually did a manual restart as well using /etc/init.d/lsws stop followed by start. So litespeed is defintely running the new 4.2.6. I also checked to make sure the binary is updated.

This ensures there are no stale copies of the aggregated css/compressed js cached on the server.

Next I accessed the site and it was working perfectly fine. After this I accessed the site on port 2080 where litespeed is running and there is no styling information available.

I did a view source and looked for a css included in the code. Tried loading the css and got the following response headers in Firefox:



In Chrome the message I get is:


The headers in Chrome look like this:


As far as I see it the new Litespeed has not made a difference. If I comment out just one line from .htaccess it starts working normally. So effectively Litespeed does not work for Drupal out of the box for us. I have tried LiteSpeed on two different servers one with and one without DirectAdmin and both throw the same issues.

If you give me a server (maybe one of the smallest droplets on DigitalOcean) I could make the time and setup the system for you the way I'm building it and deploy one of my sites there to demonstrate the problem. I wouldn't charge for this assistance if it helps, just get me a test server.
thanks for sharing, it's useful.
 
Top