Hi,

Because IEs try to download files when gzip is enable in boost, I disable gzip and re-paste the generated rules to .htaccess file. I clear the cache, the IEs are fine. I enable gzip and test around, IEs are still fine. After a while, I found that "boost-gzip-cookie-test.html not found" in log. What is the purpose of boost-gzip-cookie-test? Do I need to put these gzip rules in .htaccess file for correct running? The default rules cause IEs to download files and display a warning message. Or what is the correct way not to let IEs display such download file warning but gzip is enable? Thanks.

Comments

When I comment out "boost-gzip-cookie-test.html..." in .htaccess file, IEs will not display download file message and give me page not found log. The gzip rules may be some problems with this small gzip-test. It would be Aggressive gzip cause it since default core-gzip have no problem.

This is the Aggressive gzip test file. If you disable this setting, you shouldn't get those errors.

That is true. I turn off Aggressive gzip and works fine. I think it is better to let gzip have two options. one is for core-gzip and another is for Aggressive-gzip.

Only disabling boost in htaccess solved the problem

I had a problem (although it may come back...) with gzipped files too. Although I use Linux and FireFox. (no Microsoft anything)

Then I noticed that in my old .htaccess version the RewriteRule still had the $1 on the rewrite part. Removing that $1 fixed the different website that had a problem.

RewriteRule ^(.*)boost-gzip-cookie-test\.html $1cache/perm/boost-gzip-cookie-test\.html\.gz [L,T=text/html,E=no-gzip:1]

It'd be surprised that this is in link with this problem, but this error was not reported in the Reports and yet at some point the compressed .js files would be sent compressed and somehow the browser would take the compressed file as is (i.e. reading the compressed file as if it were an uncompressed .js file.)

If you have an idea why that would happen other than that $1, I'd be happy to learn about it!

Thank you.
Alexis Wilke

In my logs i see:
File does not exist: /var/www/madfanboy.com/boost-gzip-cookie-test.html, referer: http://www.mysite.com/site/

Rule:
# Gzip Cookie Test
RewriteRule boost-gzip-cookie-test\.html cache/perm/boost-gzip-cookie-test\.html\.gz [L,T=text/html]

This path is wrong: /var/www/site.com/boost-gzip-cookie-test.htm
Right path: /var/www/site.com/site/boost-gzip-cookie-test.htm

How I can fix it?

This issue can be caused if you have not pasted your .htaccess rules between the following.

# RewriteBase /
-------paste the rules right here--------
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]

Title:boost-gzip-cookie-test.html not found in logAggressive gzip: boost-gzip-cookie-test.html not found in log

Personally, I think the aggressive gzip is a bad idea:

* hackish (iframe, more htaccess rules, unclear working)
* only applies to some people who are behind some types of proxy/firewalls (which, one would hope, have been solved in 2012).
* generates too many weird bug reports.

Any opposition to deprecating/removing that code?

Nope, IMO getting rid of all gzip related items and relying on server compression would be better. I also propose removing the current 7.x support that's disabled in dev for html.gz in 7.x #1416214: Basic gzip support for 7x as the issues are impossible to solve (apache headers, modules conflicting, missing bytes from the sent out file caused by removal of a file's magic number on linux).

Version:6.x-1.18» 6.x-1.21
Category:support» bug

I need to re-check/improve gz-support in 7.x-1.x, but that's a separate issue. Afaik, it should/could work.
Gzipping the cache provides a good performance improvement (on my local tests, page requests went from 40ms to 5ms). It avoids Apache having to compress the file over and over again.

But we seem to agree on removing the 'agressive gzip' feature from 6.x-1.x?

Yes we agree.

I went through extensive testing on the gzip 7.x issues and I agree that it would save the server having to repeat it but there is certainly a bug in chrome in to do with it in virtually all circumstances (even on 6.x) and with other browsers the module configuration has to be very specific for it work.