Drupal CSS & JS Aggregation problem

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

  1. Xenyo

    Xenyo New Member

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

    Xenyo New Member

  3. NiteWave

    NiteWave Administrator

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

    Xenyo New Member

    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:
  5. NiteWave

    NiteWave Administrator

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

    Xenyo New Member

    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.
    Last edited: Jan 19, 2014
  7. NiteWave

    NiteWave Administrator

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

    Xenyo New Member

    Thx Nitewave,

    Any idea of approx timeframe?
  9. mistwang

    mistwang LiteSpeed Staff

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

    Xenyo New Member

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

    NiteWave Administrator

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

    Xenyo New Member

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

    mistwang LiteSpeed Staff

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

    Xenyo New Member

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

    NiteWave Administrator

    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.
    Last edited: Jan 20, 2014
  16. Xenyo

    Xenyo New Member

    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.)
    Last edited: Jan 20, 2014
  17. NiteWave

    NiteWave Administrator

  18. Xenyo

    Xenyo New Member

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

    NiteWave Administrator

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

    Xenyo New Member

    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.

Share This Page