<FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header append Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding
    </FilesMatch>

The above code use append rather than set in serving the correct encoding type, I check for documentation here - http://httpd.apache.org/docs/current/mod/mod_headers.html#Header and instead of append we can use set.

The problem I've encountered in Header append Content-Enocding gzip is I can't enable CSS and JS aggregation in Drupal performance page, the site breaks if it is installed in a Apache server which is already doing a gzip compression, the gzip in the header sent to the browser appear to be twice or appended, I attached screen-shot that can be found here to best describe the problem:

- > http://drupal.org/files/issues/bug_19.jpg
-> http://drupal.org/files/issues/bug2_2.jpg

This happens if Drupal is installed in a sub domain, a sub directory or in a multi-site setup site created using symbolic link, I have tested it in those situation. If Drupal is installed in the root directory, it seems not affected by the problem, to verify this problem I have setup a fresh install of a Drupal 7 site located here - > http://d7.levinson.com.ph

Login with user : admin/admin
go to configuration > performance
then turn on CSS / JS aggregation
VIOLA - the site is broken!

No effects even if you clear the cache several times.

Changing the code

      # Serve correct encoding type.
      Header append Content-Encoding gzip

to

      # Serve correct encoding type.
      Header set Content-Encoding gzip

seems to solve the problem.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bryancasler’s picture

subscribe

Owen Barton’s picture

I think this change looks reasonable - certainly it is safer to set than add.

The one thing I am unclear on is how this code is active - if mod_deflate is enabled the rewrite rule should not be triggered (this is the "E=no-gzip:1" part) and so the header should not be added as the file extension rule won't match. Are you using a different gzip module/setup?

danreb’s picture

nope, not using different setup, It's not clear to me also why the above rule (E=no-gzip:1) didn't work in this case.

sherakama’s picture

Thanks for this post. I am running MAMP and have to make this change to get compression to stop double compressing the aggregated files.

Thanks again.

omercioglu’s picture

sub

Coornail’s picture

Let's see

Coornail’s picture

Status: Active » Needs review
Fabianx’s picture

Subscribe.

Kars-T’s picture

Version: 7.x-dev » 8.x-dev
Issue tags: +Needs backport to D7
FileSize
535 bytes

+1 for this as it casted trouble on one of our projects because I was so foolish to copy the .htaccess one directory above my webroot and apache will scan recursively for other .htaccess files in the path. By this I had the headers set twice.

I added "set" to both header directives because it seems to make more sense.

And by the new core patch directives I move this to d8 with backport tag.

Kars-T’s picture

Title: double encoding in the header breaks Drupal sites if enable CSS and JS aggregation in Drupal performance » Use "Header set" instead of "Header append" in .htaccess to avoid faulty headers

Changed the issue title to make it more clear what we want :)

geewiz_’s picture

Title: Use "Header set" instead of "Header append" in .htaccess to avoid faulty headers » Use "Header set" instead of "Header append" in .htaccess to avoid double encoding
Status: Needs review » Reviewed & tested by the community

I think the patch should be limited to set (not append) only the ContentEncoding header. From my understanding, the Vary header can and may have a set of multiple values, so "header append" is correct in that context. By using "header set Vary", necessary values could even be lost.

(Made the title even more precise.)

Best regards,
Jochen

geewiz_’s picture

Status: Reviewed & tested by the community » Needs review

Sorry, I accidentally changed the status.

Owen Barton’s picture

Status: Needs review » Needs work

Agree with #11 regarding Vary - setting back to cnw.

Kars-T’s picture

Status: Needs work » Needs review
FileSize
787 bytes

Okay than I resubmit the Coornail from #6

Kars-T’s picture

err the patch made by Coornail ;)

Jeff Burnz’s picture

Pretty sure I am having this problem on one server, the aggregated files are gobbledygook and CSS aggregation breaks the site - I tried the patches in this queue but neither solved the issue, can anyone shed some light on another possible reason for this happening or an alternative fix?

Kars-T’s picture

Stupid question: Did you restart the apache? Do you have more .htaccess in the the folders trail?

Jeff Burnz’s picture

I do have more .htaccess files in the trail, because this site is running in a sub directory of a site already running d7, if I make a change in htaccess (otherwise) it gets picked up strait away, so do I need to reboot Apache?

I downloaded some the aggregated css files and they are not gobbledygook, only when loaded by the browser.

Coornail’s picture

What happens if you comment out the questionable line entirely?

Jeff Burnz’s picture

The problem persists, I tried this in both htaccess files - the root one in the base d7 install and in the sub-directory drupal. I also un-commented the variables in settings.php that are supposed to prevent css and js files from being compressed, but the issue still remains.

The root site has aggregation on and works no problem, its only this site I have in a sub directory that is the problem. In D6 this was no problem at all and I did this all the time.

Owen Barton’s picture

Did you apply the patch on only the sub-directory drupal, or on the parent also? Can you check and paste the http headers from the sub-directory drupal site (with firebug or wget -d or whatever)?

droplet’s picture

Owen Barton’s picture

Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

I have confirmed the "Drupal in sub-directory issue" reported by Jeff with wget -d headers and with Chrome and Firefox - you end up with a header like "Content-Encoding: gzip, gzip". This causes browsers to attempt to gunzip the content twice - however the content is actually only gzip'ed once, so the browsers fail and the resource is not included on the page.

Given that this (a) basically breaks all sub-directory sites, which are a long supported configuration, and that (b) accidentally leaving a .htaccess in a higher level directory (given the dot) is also all to easy and will confound users no end - I am raising this to "major" priority.

I was also able to validate that the patch in #14 fixes this issue (with wget -d headers, Chrome and Firefox) - the headers for the "root" and "sub-directory" sites are now identical on all counts, and both have only a single "gzip" in the Content-Encoding header. Hence, RTBC.

My guess is that the issue Jeff was having was either due to the patch not being applied in both sites, or was a caching issue (I got this the first try, since browsers only do an Etag check if you hit F5/refresh, which passes as the content itself is unchanged, yet the cached headers are still broken) - you need to disable/clear cache or Ctrl-F5 (or equivalent). Jeff - if you don't think this is the issue, please retest and include the headers (ideally header source rather than parsed).

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 7.x and 8.x.

Jeff Burnz’s picture

Owen - what I had to do was restart Apache, once I did that it all work as you describe.

Purplemonkey’s picture

Hi,

I'm afraid I'm suffering from this problem too. My site host is "justhostme" and I dont have access to restart the Apache server. I guess I can ask the provider, but I want to make sure of everything before I do. (Local install is fine (running XAMPP) but once uploaded I can't tick these boxes)

I altered my .htaccess file from append to set.
I uploaded this file to my PUBLIC_HTML folder, which is the root of my Drupal installation on this server.
(this has made a MASSIVE performance boost BTW)

someone mentioned they deleted all files in sites/default/files/css and sites/default/files/js. Now I don't have any files in these folders? I am also unsure how to check the access? I personally have access, and tried (probably wrongly) to upload the files found in my local version of the site in the same folders, this didn't make any difference though.

I've tried Clearing Cache, and CTRL+F5 after ticking the box, but to no success.

sorry to bring it up, as it appears to me that everyone else is now sorted. I appreaciate any feedback.

thanks

RdeBoer’s picture

Having the same issue as Purplemonkey, #26.... If a restart of Apache is required, how can we prod it into action?

Owen Barton’s picture

Note that I did not need to restart Apache in my tests - the fix was immediate. I did need to clear or force refresh my browser cache however (the files are not redownloaded on a normal refresh/F5).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Danny_Joris’s picture

Sorry to post in a closed issue, but I have the same problem, but this didn't solve the problem.

http://drupal.org/node/1402834

onyxnz’s picture

Still affecting us on D7. Fix mentioned here: http://drupal.org/node/1440534