A site is not visible in MSIE 5.5, 6.0 in Windows

I created no special tuning. Included the module and it began to work, but discovered then, that browsers Links and MSIE 6.0 and 5.5 under Windows 2000 try to get my site as file.

I've ran into this problem too. It only happens if you're behind a proxy. The file it tries to load is a gzipped version of the cached page.

The total extent of this bug is still quite unclear to me, but it certainly also happens in XP. Not sure, if it happens in IE7. And I'm not completely sure if this happens with all proxies, or only with some, but it seems that only with some.

It also seems that this browser and the version of Apple's Safari that was shipped with Mac OS 10.3 (i.e. Safari 1.0) can trigger it every time, even when not behind a proxy. But it is really hard to be 100 % sure, because I don't have access to any proxies so that I could test it personally.

I encountered this problem as well including running "links example.com" from the local server that didn't have a reverse proxy on it, so I'm not sure that it's strictly related to proxies. My resolution was simply to clear the cache and it started working again fine. Maybe my symptom was the same but the causes are different.

Same here. Some users of my community reported this problem, they can not access the website!
It's kind of sad, because the module works great. It has freed a lot of resources on my server, but it looks I'm going to have to disable it :(

Any fix for this?

Is anyone actively using this module, and still running into this problem? What's the easiest way to duplicate it? (On Linux, if possible)

I ran into it today. I'm not sure how to repeat it because it seems to happen randomly. The problem today was with a feed page that I was downloading via drupal_http_request (i.e. aggregator) and then wget. In aggregator I got a "blank page" error and wget seemed to be full of garbage characters (or compressed data).

I don't know how to reproduce it, I just know that it happens occasionally.

Thanks for the feedback! How long does the problem last? Is the solution each time to manually delete the cache, and let it build new cache files?

Yeah, the problem lasts until I remove the cache files.

I agree, it's active needs more info since we don't have steps to repeat yet.

This is a possible way to reproduce this issue.

login to your site as any user or admin. Do some browsing and log out. The moment you hit the logout button the file that arrives from the server is gzip file and the browser (IE6) does not know how to open it.........It tells us to download the file !

I tried to fix the problem by putting this fix .....in cache.fs.inc

===========================================================
function page_cache_fastpath() {
global $base_root;
if (empty($_POST) && !$_COOKIE['drupal_uid']) {
$file_cache = variable_get('file_cache', FASTPATH_FSCACHE_PATH);
if ($file_cache && is_dir($file_cache)) {
$cache = cache_get($base_root . request_uri(), 'cache_page');
if (!empty($cache)) {
drupal_page_cache_header($cache);
/* tthis is the orginal code

// display cached page and exit
drupal_page_header();
if (function_exists('gzencode')) {
header('Content-Encoding: gzip');
}
print $cache->data;
*/
return TRUE;
}
}
}
else {
// If $_POST is not empty, the user has submit a form (ie a comment was
// posted) so we don't serve the page from the cache, instead letting Drupal
// process the form submission. If the 'drupal_uid' is set, a logged in
// user is viewing the page and so again we don't serve the page from the
// cache.
return;
}
}
================================================
This has worked for me as the function drupal_page_cache_header($cache); will check whether gzip is acceptable........if yes ....it sends gzip else it sends unzipped version.......it also sets the headers properly..............I still do not know whether this was/is the problem and whther the fix is 'the' complete fix or not............

I thought this would help in improvement, as this module is extremely important to me.

An extreme solution is to do away with gzip and unzip everywhere in code..........and it works okay.

I have never seen this issue, but users from my website have reported it. They were unable to access for a while before they reported the error and I disabled the module. All of them were using IE6, so I guess the problem is with the gzip files sent, not with the module itself.

I haven't tried Velankar's solution yet. I was hoping there would be no more IE6 users out there, but looks like that won't happen soon.

I'm doing more testing on this issue tonight and it seems like everything works fine. Testing on Safari, Firefox, IE 6, MacOSX and Windows and haven't found any problem.

Either way, taking a better look at the code posted by Velankar, it seems like he is commenting out the whole print $cache->data; That means the user will get an empty page, right?

I'd similar problem but without this module here: #324890: weird unreadable compressed front page

Can anybody test this patch:
http://drupal.org/node/440182#comment-1501004
It's for 6.x, but it should work for 5.x as well.

kenorb, I do not think that your patch is sufficient. It should at least check, whether page compression is enabled in Drupal, otherwise all these gzip headers only cause trouble when other compression mechanisms are active.

As a sidenote - I think that the whole page compression function in Drupal is not correct. Compression decisions should be based upon negotiation between server and client.

Could be related to those:
#97847: cached pages appear blank, or garbage, or gzinflate error
#43462: cache_set and cache_get base_url brokenosity
#187912: Problems with cache and zlib.output_compression

And also: http://drupal.ro/drupal-caching-php-zlib-compression-problems

Basically it's duplicated of: #43462: cache_set and cache_get base_url brokenosity

Workaround:
- If you using PHP4, please upgrade it to PHP5
- Disable page compression
- Disable zlib.output_compression in your php.ini configuration