<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.
Comment | File | Size | Author |
---|---|---|---|
#14 | use_set_rather_than_append-1116416-6.patch | 787 bytes | Kars-T |
#9 | use_set_rather_than_append-1116416-7.patch | 535 bytes | Kars-T |
#6 | use_set_rather_than_append-1116416-6.patch | 787 bytes | Coornail |
Comments
Comment #1
bryancasler CreditAttribution: bryancasler commentedsubscribe
Comment #2
Owen Barton CreditAttribution: Owen Barton commentedI 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?
Comment #3
danreb CreditAttribution: danreb commentednope, 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.
Comment #4
sherakama CreditAttribution: sherakama commentedThanks 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.
Comment #5
omercioglu CreditAttribution: omercioglu commentedsub
Comment #6
Coornail CreditAttribution: Coornail commentedLet's see
Comment #7
Coornail CreditAttribution: Coornail commentedComment #8
Fabianx CreditAttribution: Fabianx commentedSubscribe.
Comment #9
Kars-T CreditAttribution: Kars-T commented+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.
Comment #10
Kars-T CreditAttribution: Kars-T commentedChanged the issue title to make it more clear what we want :)
Comment #11
geewiz_ CreditAttribution: geewiz_ commentedI 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
Comment #12
geewiz_ CreditAttribution: geewiz_ commentedSorry, I accidentally changed the status.
Comment #13
Owen Barton CreditAttribution: Owen Barton commentedAgree with #11 regarding Vary - setting back to cnw.
Comment #14
Kars-T CreditAttribution: Kars-T commentedOkay than I resubmit the Coornail from #6
Comment #15
Kars-T CreditAttribution: Kars-T commentederr the patch made by Coornail ;)
Comment #16
Jeff Burnz CreditAttribution: Jeff Burnz commentedPretty 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?
Comment #17
Kars-T CreditAttribution: Kars-T commentedStupid question: Did you restart the apache? Do you have more .htaccess in the the folders trail?
Comment #18
Jeff Burnz CreditAttribution: Jeff Burnz commentedI 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.
Comment #19
Coornail CreditAttribution: Coornail commentedWhat happens if you comment out the questionable line entirely?
Comment #20
Jeff Burnz CreditAttribution: Jeff Burnz commentedThe 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.
Comment #21
Owen Barton CreditAttribution: Owen Barton commentedDid 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)?
Comment #22
droplet CreditAttribution: droplet commentedmaked dup: #986558: "Aggregate and compress CSS files" and "Aggregate JavaScript files" in performance settings, is not working
Comment #23
Owen Barton CreditAttribution: Owen Barton commentedI 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).
Comment #24
Dries CreditAttribution: Dries commentedCommitted to 7.x and 8.x.
Comment #25
Jeff Burnz CreditAttribution: Jeff Burnz commentedOwen - what I had to do was restart Apache, once I did that it all work as you describe.
Comment #26
Purplemonkey CreditAttribution: Purplemonkey commentedHi,
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
Comment #27
RdeBoerHaving the same issue as Purplemonkey, #26.... If a restart of Apache is required, how can we prod it into action?
Comment #28
Owen Barton CreditAttribution: Owen Barton commentedNote 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).
Comment #30
Danny_Joris CreditAttribution: Danny_Joris commentedSorry to post in a closed issue, but I have the same problem, but this didn't solve the problem.
http://drupal.org/node/1402834
Comment #31
onyxnz CreditAttribution: onyxnz commentedStill affecting us on D7. Fix mentioned here: http://drupal.org/node/1440534