Drupal CSS & JS Aggregation problem

Discussion in 'General' started by Xenyo, Jan 18, 2014.

  1. NiteWave

    NiteWave Administrator

    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)
  2. Xenyo

    Xenyo Member

    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.

    After the force upgrade I removed all cache from my drupal install using the webinterface as well as running this command:

    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:

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

    NiteWave Administrator

    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
      <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
    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 ? :)
  4. Xenyo

    Xenyo Member

    When you say, not work ... which part do you mean?

    I mean obviously ;

    Header set Content-Encoding gzip

    is working hence the problem right?
  5. NiteWave

    NiteWave Administrator

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

    mistwang LiteSpeed Staff

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

    Xenyo Member


    Yes there are multiple .htaccess .

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

    Any approx. timeframe on 5.0 ?
  8. NiteWave

    NiteWave Administrator

  9. mistwang

    mistwang LiteSpeed Staff

    Double checked with our 5.0 branch, it is addressed, the first 5.0 release candidate will be available in next week.
  10. tonytong

    tonytong New Member

    thanks for sharing, it's useful.

Share This Page