boost-gzip-cookie-test redirection

Thats very odd... I load up an iframe/object on browsers that say they do not support gzip & test to see if they are lieing about supporting gzip. A lot of them do lie about gzip support so this is a way to serve gzip to those who do support it but do not say so. Makes your site load faster for more people. You can turn this off. Disable Aggressive Gzip and it will no longer run this test.

I'm now curious about this; why would a iframe/object cause a redirect to it's contents? IE is very strange...

I have a feeling this is related...
#674664: Boost breaks W3 XHTML/HTML5 validation
Can you try the latest dev to see if this problem goes away? If you can even test this...

@morningtime
Looks like you have already disabled aggressive gzip. I'll work on this later tonight... I'll come up with multiple solutions and try to find out which one works best. Doing a google search for IE redirect issue brings up malware removal; so finding out the why will be hard...

My guess is a firewall removes the Content-Encoding: gzip header from the gzip test; when IE gets a document it can't parse, it redirects to the actual document when it's inside the object tag. Using some htaccess trickery I should be able to reproduce these conditions and see if I can reproduce the bug.

It works! - Default Apache server text in case you where wondering. I should probably add in meta no follow no index tags just to be safe now that I think about it.
http://www.tedxmunich.com/boost-gzip-cookie-test.html

Today I received a email from Google saying our site(www.intematrix.cn) was detected as being infected by malware. Google posts a warning sign to every page of our site to warn visitors. We spent the whole day trying to identify the problem and finally found that it's related to the Boost module. We disabled Boost and cleaned all cached pages. And submitted a review request to Google. Now the site is back to normal.

When configuring the Boost module, the 'gzip' was checked and a line of code added the source code (iFrame boost-gzip-cookie-test.html). Maybe this opens door to hackers.

Maybe this opens door to hackers

Highly unlikely, this check does not run any PHP, the logic is 100% client side (static html).

I think the best option is to go back to an iframe, but use javascript to create the iframe; that way it will pass validation tests. Also if they have JS disabled then they will not do the request, a good thing, since the test uses javascript to set the boost cookie.

Seems I am coming across the same problem. A handful of users are unable to access from work. Obviously firewall related.

Looking forward to a way to keep aggressive gzip in the future. It's a shame to have to turn it off because of a small number of IE/firewall visitors.

One of my users reported this same issue but I cannot reproduce it. Any ideas on how to fix it?

I am looking to fix this, any solution ?

I ran into this problem with a website I built. It was showing fine for me and others in Firefox, Opera, IE8, IE7, but then someone else got this problem: for a fraction of a second the site showed fine, then it redirected to /boost-gzip-cookie-test.html. That person was using IE8 - strange that the behavior is not the same for all IE8 browsers...

The suggestion in #1 solved it: uncheck "Aggressive setting of the boost cookie".
Then only after I cleared both the Boost Cache and the Drupal caches and hit refresh did the site come up OK (but maybe this part was a browser caching issue?). All seems to be working fine now.

all you need to do is flush the front page cache, after Disabling Aggressive Gzip.

subscribing

Subscribe - Disabling the "Clear all cached pages in a menu on an insert/update/delete operation:" fixed it for me (along with disabling the "Aggressive setting of the boost cookie."

This was interfering with a drush update script that I had running on my server, which was in turn using migrate to update a few thousand nodes - when the nodes weren't updating, I found that boost was the culprit—very odd!

able to semi repo this bug. Can't get IE to redirect (like in the screen shots) but I can get it to display the download bar. Thinking of alts, and I think AJAX might be the ticket.

Odd hack needed since ajax doesn't pass the XMLHttpRequest object in success if jQuery < 1.4 (Drupal 6 uses 1.2.6) and I don't want to block the javascript on this page.

function boost_gzip_test_ready() {
  if(xhr.readyState != 4) {
    setTimeout(boost_gzip_test_ready, 1000);
  }
  else {
    alert(xhr.getResponseHeader('Content-Encoding'));
    alert(xhr.responseText);
    alert(xhr.getAllResponseHeaders());
  }
}

var xhr = $.ajax({
  url: "/boost-gzip-cookie-test.html",
});
boost_gzip_test_ready();

If the getResponseHeader('Content-Encoding') returns gzip then do something with the responseText (like run it if its javascript). This should be a heck of a lot safer then using an iframe. If Content-Encoding is not set it returns null. JS Code above is demo code for firebug.

here it is; not easy being a front runner.

patch might apply to 1.18, its worth trying

committed