Normal caching mode causes white screen for IE6 [#227294]

Following up on an issue that affected a friend of mine, also noted at http://drupal.org/node/143643

Essentially, with 'normal' caching mode enabled, IE6 users were getting a blank page on the second load of an arbitrary URL.

The problem seems to be in drupal_cache_header, and exists in Drupal 5 and 6.
(http://api.drupal.org/api/function/drupal_page_cache_header)

Below you'll see the header dumps for IE6 and Firefox that helped me figure this out.

As you can see, IE6 appends a "; length=..." entity to the If-Modified-Since request header. Additionally, IE6 does not respect the use of ETags.

The first is trivial to fix with a regex. The second, since the ETags you seem to use are a basic md5 of the last modified date (i.e., basically redundant), is just as simple to compensate for.

The patches below are marked with // *** description

function drupal_page_cache_header($cache) {
  // Set default values:
  $last_modified = gmdate('D, d M Y H:i:s', $cache->created) .' GMT';
  $etag = '"'.md5($last_modified).'"';

  // See if the client has provided the required HTTP headers:
  // *** Added preg_replace; some browsers append a "; length=..." entity to the header
  $if_modified_since = isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) ? preg_replace('/;.*$/','',stripslashes($_SERVER['HTTP_IF_MODIFIED_SINCE'])) : FALSE;
  $if_none_match = isset($_SERVER['HTTP_IF_NONE_MATCH']) ? stripslashes($_SERVER['HTTP_IF_NONE_MATCH']) : FALSE;

  // *** Added:
  // ***IE6 does not support Entity Tags, so depend on the if_modified_since to guide us.
  if (preg_match('/MSIE\s6\.\d+/i',$_SERVER['HTTP_USER_AGENT']) && $if_modified_since!==false)
		$if_none_match = '"'.md5($if_modified_since).'"';

  if ($if_modified_since && $if_none_match
      && $if_none_match == $etag // etag must match
      && $if_modified_since == $last_modified) {  // if-modified-since must match
    header('HTTP/1.1 304 Not Modified');
    // All 304 responses must send an etag if the 200 response for the same object contained an etag
    header("Etag: $etag");
    exit();
  }

  // Send appropriate response:
  header("Last-Modified: $last_modified");
  header("ETag: $etag");

  // The following headers force validation of cache:
  header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
  header("Cache-Control: must-revalidate");

  // Determine if the browser accepts gzipped data.
  if (@strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') === FALSE && function_exists('gzencode')) {
    // Strip the gzip header and run uncompress.
    $cache->data = gzinflate(substr(substr($cache->data, 10), 0, -8));
  }
  elseif (function_exists('gzencode')) {
    header('Content-Encoding: gzip');
  }

  // Send the original request's headers. We send them one after
  // another so PHP's header() function can deal with duplicate
  // headers.
  $headers = explode("\n", $cache->headers);
  foreach ($headers as $header) {
    header($header);
  }

  print $cache->data;
}

Header dumps:

Mozilla (first try):

GET http://localhost/work HTTP/1.1
Accept-Language: en-us,en;q=0.5
Pragma: no-cache
Cache-Control: no-cache
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Host: localhost
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Cookie: SESS26bb99f0cadcebe187fddf01aa93ab47=v145pl62tngok2f9ighres4683; __utma=175679715.93649940.1204101961.1204101961.1204101961.1; __utmb=175679715.23; __utmc=175679715.23; __utmz=175679715.1204101961.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://localhost/

HTTP/1.1 200 OK
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate
ETag: "a002a6eb6ee5781b00740ad47387d932"
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Connection: close
Date: Wed, 27 Feb 2008 02:15:41 GMT
Server: Apache
Last-Modified: Wed, 27 Feb 2008 02:10:44 GMT

Mozilla (second try):

GET http://localhost/work HTTP/1.1
Accept-Language: en-us,en;q=0.5
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Host: localhost
Accept-Encoding: gzip,deflate
If-None-Match: "a002a6eb6ee5781b00740ad47387d932"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Cookie: SESS26bb99f0cadcebe187fddf01aa93ab47=v145pl62tngok2f9ighres4683; __utma=175679715.93649940.1204101961.1204101961.1204101961.1; __utmb=175679715.24; __utmc=175679715.24; __utmz=175679715.1204101961.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://localhost/work
If-Modified-Since: Wed, 27 Feb 2008 02:10:44 GMT

HTTP/1.1 304
Etag: "a002a6eb6ee5781b00740ad47387d932"
Content-Type: text/html
Connection: close
Date: Wed, 27 Feb 2008 02:16:18 GMT
Server: Apache

IE6 (first try):

GET http://localhost/work HTTP/1.0
Accept-Language: en-us
Pragma: no-cache
Accept: */*
Host: localhost
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Cookie: SESS26bb99f0cadcebe187fddf01aa93ab47=kdnsbghc61kau5o525hos0vcl6
Proxy-Connection: Keep-Alive
Referer: http://localhost/

HTTP/1.1 200 OK
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate
ETag: "a002a6eb6ee5781b00740ad47387d932"
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Connection: close
Date: Wed, 27 Feb 2008 02:12:21 GMT
Server: Apache
Last-Modified: Wed, 27 Feb 2008 02:10:44 GMT

IE6 (second try):

GET http://localhost/work HTTP/1.0
Accept-Language: en-us
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
Host: localhost
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Cookie: SESS26bb99f0cadcebe187fddf01aa93ab47=kdnsbghc61kau5o525hos0vcl6
Proxy-Connection: Keep-Alive
Referer: http://localhost/work
If-Modified-Since: Wed, 27 Feb 2008 02:10:44 GMT; length=18016

HTTP/1.1 500 Internal Server Error
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate
ETag: "a002a6eb6ee5781b00740ad47387d932"
Content-Type: text/html; charset=iso-8859-1
Content-Encoding: gzip
Connection: close
Date: Wed, 27 Feb 2008 02:13:00 GMT
Server: Apache

Comment	File	Size	Author
#17	ie6_cache.patch	1.21 KB	redndahead
#14	ie6_no_gzip.patch	1.23 KB	bcn

Comments

Comment #1

fiLi commented 2 March 2008 at 02:25

I had this same problem, and your patch worked for me. I'll let it run for a while to make sure, but it looks good.

Thanks for posting this.

Comment #2

Joe_41170 commented 12 March 2008 at 17:07

I had the same problem. I've been beating my head against the wall for three days over this because without the normal catching mode enabled my website was slow as a turtle.

Your patch seems to work great, no problems now. Thank you very much!

Comment #3

CompShack commented 1 April 2008 at 04:25

I'm having the same problem when enabling Caching mode. What file is this function (drupal_page_cache_header) from?

Thanks for your help.

Edit: I found the file - I will test and report back!

Comment #4

CompShack commented 1 April 2008 at 16:17

Already, now I can turn Cache mode on and no problems in IE6 :) - I was getting a white blank page when guests visit the site. Guests would see the pages fine for the 1st visit but then when things gets cached, visitors will see white pages all over the place!

Thanks for the fix - so far works great. Site runs a lot faster. I Will report back if I notice any side effects.

Comment #5

drumm

he/him

NY, US

commented 3 April 2008 at 06:32

Version:	5.7	» 7.x-dev
Status:	Needs review	» Active

No patch file is attached. Please see http://drupal.org/patch/create.

This should be fixed in the current development version, where there are more active reviewers, first.

Comment #6

dcoun commented 11 May 2008 at 13:26

Version:

7.x-dev

» 6.2

I confirm this problem but it is not solved with the above patch.
It happens in every page when refreshing.
IE 6.0.2900.2180

Comment #7

dcoun commented 6 June 2008 at 17:29

I have tested it more. It does work when a user has logged on, not for the visitors.

Comment #8

dcoun commented 8 June 2008 at 11:15

After patching the first post's changes. Just to describe it better:

Initial request (headers):

GET /el HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: el
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; http://bsalsa.com) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.mysite.gr
Connection: Keep-Alive
Cookie: SESSddef35b6e1aac8ae697d3d5a8a4709a8=ef6b68feb8a1758cd9330fd2cd9d8448

Initial response (header)

HTTP/1.1 200 OK
Date: Sun, 08 Jun 2008 10:35:58 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
X-Powered-By: PHP/5.1.2
Set-Cookie: SESSddef35b6e1aac8ae697d3d5a8a4709a8=ef6b68feb8a1758cd9330fd2cd9d8448; expires=Tue, 01 Jul 2008 14:09:18 GMT; path=/; domain=.mysite.gr
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Sun, 08 Jun 2008 10:35:58 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Content-Length: 7857
Connection: close
Content-Type: text/html; charset=utf-8

Request during first reload-refresh (headers)

GET /el HTTP/1.1
Accept: */*
Accept-Language: el
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; http://bsalsa.com) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.mysite.gr
Connection: Keep-Alive
Cookie: SESSddef35b6e1aac8ae697d3d5a8a4709a8=ef6b68feb8a1758cd9330fd2cd9d8448; has_js=1

Response during first reload-refresh (headers)

HTTP/1.1 200 OK
Date: Sun, 08 Jun 2008 10:36:08 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
X-Powered-By: PHP/5.1.2
Set-Cookie: SESSddef35b6e1aac8ae697d3d5a8a4709a8=ef6b68feb8a1758cd9330fd2cd9d8448; expires=Tue, 01 Jul 2008 14:09:28 GMT; path=/; domain=.mysite.gr
Last-Modified: Sun, 08 Jun 2008 10:35:58 GMT
ETag: "8f2c9c32093545617a686b25ff1a6493"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate
Content-Encoding: gzip
Content-Length: 3135
Connection: close
Content-Type: text/html; charset=utf-8

The webpage's source is included in the second response but IE shows a white page with the following as page source:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8"></HEAD>
<BODY></BODY></HTML>

Request during second or more reload-refresh (headers)

GET /el HTTP/1.1
Accept: */*
Accept-Language: el
Accept-Encoding: gzip, deflate
If-Modified-Since: Sun, 08 Jun 2008 11:06:45 GMT
If-None-Match: "8ae0edb639e29bd9d4d98be774266767"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; http://bsalsa.com) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.mysite.gr
Connection: Keep-Alive
Cookie: SESSddef35b6e1aac8ae697d3d5a8a4709a8=ef6b68feb8a1758cd9330fd2cd9d8448; has_js=1

Response during second or more reload-refresh (headers)

HTTP/1.1 304 Not Modified
Date: Sun, 08 Jun 2008 11:08:41 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
Connection: close
Etag: "8ae0edb639e29bd9d4d98be774266767"

The white empty page is still here in IE6

Comment #9

dcoun commented 8 June 2008 at 11:57

If you make a clean cache data, IE6 loads the page during refresh and replaces the white page with the actual webpage, but in the next refresh, the white page comes again.
Please help, drupal cache is useless with this bug.

Comment #10

dcoun commented 8 June 2008 at 12:57

Finally it was solved after disabling module clickpath. I do not know why, but now it works.

Comment #11

XakepaBG commented 10 June 2008 at 16:15

Hello everybody,

It seems to me the bug only appears when the IE6 has a bug in the combination of reporting gzip support, but failing to do it properly.
This happens to IE6 before the SP2 update of WinXP, I think.

So, if you excuse me, try forgetting about the patch up there, and only (in bootstrap.inc) replace this:

  // Determine if the browser accepts gzipped data.
  if (@strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') === FALSE && function_exists('gzencode')) {
    // Strip the gzip header and run uncompress.
    $cache->data = gzinflate(substr(substr($cache->data, 10), 0, -8));
  }
  elseif (function_exists('gzencode')) {
    header('Content-Encoding: gzip');
  }

with this:

 	// Check for buggy versions of Internet Explorer
	if (!strstr($_SERVER['HTTP_USER_AGENT'], 'Opera') && preg_match('/^Mozilla\/4\.0 \(compatible; MSIE ([0-9]\.[0-9])/i', $_SERVER['HTTP_USER_AGENT'], $matches)) {
		$version = floatval($matches[1]);
		if ($version < 6)
			$damn_ie6 = true;
		if ($version == 6 && !strstr($_SERVER['HTTP_USER_AGENT'], 'EV1'))
			$damn_ie6 = true;
	} 
  
  // Determine if the browser accepts gzipped data.
  if (((@strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') === FALSE)||($damn_ie6)) && (function_exists('gzencode'))){
    // Strip the gzip header and run uncompress.
    $cache->data = gzinflate(substr(substr($cache->data, 10), 0, -8));
  }
  elseif (function_exists('gzencode')) {
    header('Content-Encoding: gzip');
  }

and your visitors with IE6 featuring the faulty gzip support should be served plain pages instead of gzipped pages

I hope this helps any of you

:-)

Comment #12

johnalbin

they/他

English

Taipei, Taiwan

commented 15 June 2008 at 22:47

Title:	IE6 500 error on drupal_page_cache_header	» Normal caching mode causes white screen for IE6 (pre SP2)
Version:	6.2	» 7.x-dev

A real patch would be nice. :-) http://drupal.org/patch/create

Comment #13

lias commented 23 June 2008 at 15:11

subscribing

Comment #14

bcn commented 24 June 2008 at 11:25

Status:

Active

» Needs review

Status	File	Size
new	ie6_no_gzip.patch	1.23 KB

This is basically just the changes described in #11. Not sure if this is the right approach, or even if it works... I just rolled the patch.

Comment #15

wpanssi commented 12 July 2008 at 18:05

I followed instructions on #11. With IE 6 page caching seems to wlrk, no white screens BUT with IE 7 I get:

*Notice*: Undefined variable: damn_ie6 in *
/home/sitemedia/public/html/includes/bootstrap.inc* on line *593*

*Warning*: Cannot modify header information - headers already sent by
(output started at /home/sitemedia/public/html/includes/bootstrap.inc:593)
in */home/sitemedia/public/html/includes/bootstrap.inc* on line *598*

*Warning*: Cannot modify header information - headers already sent by
(output started at /home/sitemedia/public/html/includes/bootstrap.inc:593)
in */home/sitemedia/public/html/includes/bootstrap.inc* on line *607*

Does someone know how to get this working - without side effects??

Tnks in advance!

Comment #16

wpanssi commented 12 July 2008 at 21:37

Ok, I think it's #11 that just doesn't work. With the original patch presented in the first post it seems to work, so far..

Comment #17

redndahead commented 13 July 2008 at 15:16

Status	File	Size
new	ie6_cache.patch	1.21 KB

Here is an updated version of the patch. declared $damn_ie6 var to fix issue in #15. Also renamed $damn_ie6 to $is_ie6. Watch your language ;) Plus it reads better. Combined two if statements. Not tested as I don't have IE6

Comment #18

XakepaBG commented 23 July 2008 at 06:56

Hi all,

haha, watch the language, lol :-) sure

Of course it'll fail, #15/16 - you have your Error Reporting in your PHP set to cry and moan about EVERY little pseudo-issue - such as having a variable not defined prior to an assignment operation(something PHP happily forgives altogether). Then the error message sends text to the browser, and some subsequent header redirect doesn't work :-)

For development - most people have Notices disabled
For production - most people have all error reporting disabled
play with PHP's manual and error_reporting() and co :-)

Nice save, #17, when I initially found the solution I rushed to post it here and save some suicidal lives :-)
well done to you, optimizing the code for generations to use :-)

Comment #19

cburschka

they

commented 23 July 2008 at 08:44

Of course it'll fail, #15/16 - you have your Error Reporting in your PHP set to cry and moan about EVERY little pseudo-issue - such as having a variable not defined prior to an assignment operation(something PHP happily forgives altogether). Then the error message sends text to the browser, and some subsequent header redirect doesn't work :-)

Drupal core is required not to print notices regardless of what level error reporting is set to, mainly because most developers have it on and would very much prefer their test site not being broken. Also, "pseudo-issue" is kind of subjective; reading an unset variable is definitely sloppy coding. ;)

Edit: I cannot test this patch. I have IE 6, but post-SP2, and the issue does not exist for me.

Comment #20

ezra-g commented 26 August 2008 at 21:39

Can someone post instructions for reliably recreating this issue with IE6 and fresh Drupal install? Also the Microsoft support page for this issue appears to be http://support.microsoft.com/default.aspx?scid=kb;en-us;823386&Product=i....

Comment #21

CompShack commented 15 September 2008 at 16:25

Why can't we get this fixed in D6?!! I upgraded my site from D5.7 to D6.4 and the problem remained. I was having the same problem in D5. over 60% of my site visitors still use IE6, it sucks but there is nothing i can do about it. I've tested this with ie6 version version: 6.0.2900.2180.xpsp_sp2_gdr

I will have to re-apply the fix and report back.

Comment #22

redndahead commented 16 September 2008 at 04:37

It definitely won't get fixed unless it goes RTBC. So if it works for you please post instructions to test and change the status to RTBC.

Comment #23

millions commented 25 September 2008 at 04:14

Comment #24

millions commented 25 September 2008 at 15:04

I'm getting this error when I go to admin/build/modules after applying the patch:

Parse error: syntax error, unexpected $end in bootstrap.inc on line 998

Comment #25

millions commented 25 September 2008 at 15:21

Looks like I was missing an end bracket. thanks.

Comment #26

millions commented 25 September 2008 at 16:04

This seems to have worked to fix IE6, but now I'm having this problem: http://drupal.org/node/121820 where in Opera and Firefox the home page shows as gibberish. Disabling caching fixes that problem as well. Is there a patch that makes caching work in IE6 AND Opera/Firefox?

Comment #27

redndahead commented 25 September 2008 at 21:02

Status:

Needs review

» Reviewed & tested by the community

I think that's a confirmation from xoso for the patch working. Setting to RTBC

Opera and FF issues should be worked out in the other issue queue.

Comment #28

johnalbin

they/他

English

Taipei, Taiwan

commented 25 September 2008 at 21:23

Status:

Reviewed & tested by the community

» Needs review

Actually, if Xoso applied the patch but had a missing end bracket (in #24 & #25). that's not a confirmation that the patch works.

Also, its sounds like the patch caused the Opera/Firefox issues. But perhaps I'm misreading.

Wish I could help with this issue, but I can't reproduce.

Comment #29

millions commented 25 September 2008 at 22:08

Something in my settings with the patch caused the Opera/Firefox issue. It sounds like it has to do with the gzip, but I don't know enough about coding to try to fix it. I have caching disabled at the moment...

Comment #30

redndahead commented 27 September 2008 at 14:51

Status:

Needs review

» Reviewed & tested by the community

I'm pretty sure the missing end bracket was his mistake when applying the patch. There are no missing brackets in the patch. I just tested to see if this patch messes with opera/firefox and the code does not affect these browsers. Setting it back to RTBC.

Comment #31

millions commented 29 September 2008 at 13:49

Something in the patch, I believe combined with apache, is causing the opera/firefox issue. All I know is without this patch opera/firefox work and ie6 doesn't, and with it it's reversed. With the caching disabled they all work.

Comment #32

dries commented 29 September 2008 at 13:54

Personally, I'm not a big fan of browser specific hacks.

Comment #33

redndahead commented 29 September 2008 at 19:42

Status:

Reviewed & tested by the community

» Needs review

Dries,

Understandable but since this causes a white screen we either need to document that it is a known issue in IE6 or patch it. If you would like to document it just tell me where and I'll take care of it.

Comment #34

millions commented 2 October 2008 at 12:15

Version:	7.x-dev	» 5.10
Category:	bug	» support

It would be great if someone can help me figure out why this is causing the gibberish rendered page in Firefox with caching enabled. It only happens for anonymous users.

So to sum up:

With Caching enabled 1 of two things occurs:

1)No IE6 patch means FF works fine, IE6 displays a blank page on 2nd load or refresh for anonymous users.
2)With IE6 patch means FF displays gibberish on 2nd load or refresh for anonymous users.

With Caching disabled both work fine, although slower.

I don't believe my issue has to do with my post in #26 because I don't believe I have zlib and I don't have that problem without applying this ie6 workaround.

Comment #35

millions commented 2 October 2008 at 12:26

I am running XML Sitemap 1.6 (unrelated to this problem) which I believe does require zlib so maybe I do have it.

I tried adding php_flag zlib.output_compression off (or on) to my .htaccess file in both with and without the IE6 patch and it just created 500 Internal Server Errors and my site would not load.

Comment #36

johnalbin

they/他

English

Taipei, Taiwan

commented 2 October 2008 at 12:28

Version:	5.10	» 7.x-dev
Category:	support	» bug
Status:	Needs review	» Needs work

You don't need to change the status of the issue to get help with this patch. If the patch breaks Firefox, the patch needs to be improved.

Comment #37

millions commented 2 October 2008 at 13:38

Version:	7.x-dev	» 5.10
Category:	bug	» support
Status:	Needs work	» Needs review

sorry about that, just trying to find some answers!

I also tried my sites/default/settings.php file with ini_set('zlib.output_compression', 'Off') and that didn't work either.

I'm on Godaddy, I have access to my php.ini file on the site, but running phpinfo says that the loaded file is php5.ini which is not in my root directory...

Comment #38

millions commented 2 October 2008 at 13:39

Version:	5.10	» 7.x-dev
Category:	support	» bug
Status:	Needs review	» Needs work

Comment #39

redndahead commented 2 October 2008 at 16:49

Xoso,

I really don't know what your issue is, but put a drupal_set_message('Not using gzip') after

 if (((@strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') === FALSE)||($is_ie6)) && (function_exists('gzencode'))){

and you should see that the message never gets displayed in FF or Opera. So I'm not sure how this patch can affect FF or Opera.

Comment #40

millions commented 2 October 2008 at 17:34

Thanks for the help, can you tell me exactly what/where I should paste please so I can try it out?

Comment #41

redndahead commented 2 October 2008 at 19:11

If you look at the last bit of the patch you will see this:

 if (((@strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') === FALSE)||($is_ie6)) && (function_exists('gzencode'))){
       // Strip the gzip header and run uncompress.
       $cache->data = gzinflate(substr(substr($cache->data, 10), 0, -8));
     }

After you patch your database.inc file look for that section and change it to this:

 if (((@strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') === FALSE)||($is_ie6)) && (function_exists('gzencode'))){
        drupal_set_message('Not using gzip');    

       // Strip the gzip header and run uncompress.
       $cache->data = gzinflate(substr(substr($cache->data, 10), 0, -8));
     }

Comment #42

millions commented 2 October 2008 at 22:25

Thanks, I tried that and still get the binary results with caching enabled in FF. This is supposed to be in the bootstrap.inc right? not the database.inc?

Thanks for your help

Comment #43

redndahead commented 2 October 2008 at 22:44

Yes sorry my brain was thinking about another patch at the same time. Can you create a test installation of drupal on your server with the default settings, apply the patch and see if you still have the issue?

Comment #44

millions commented 9 November 2008 at 09:51

Just an update... I had read here (http://drupal.org/node/143641#comment-948227) that this may be host dependent. I was on godaddy and switched to another host today. I enabled caching, and checked IE6 and saw that it was working so I was ecstatic. Later I realized I still had the patched version of bootstrap.inc running and it was causing the gibberish or double compression in Firefox still.

I reverted to the original bootstrap.inc (removed the earlier patch in #17), and now Firefox is working as I expected it would, but the IE6 problem has been fixed as well.

Could it be that the IE6 blank screen is really just host dependent somehow?

Also, this means that somewhere there is a setting (on both hosts) that conflicts with the patch posted above, but I don't know enough to try to find out what it is.

Comment #45

PixelClever commented 14 January 2009 at 15:56

This is showing up for me also on Drupal 6.6. I don't think it is a server configuration issue, I could be wrong though.
Disabling the page compression takes care of the issue for me. Not an ideal solution, but at least the site doesn't look like it's down for IE users.

Comment #46

senyahnoj commented 26 May 2009 at 14:54

looks like a problem with apache mod_deflate (gzip) and ie6:

http://support.microsoft.com/kb/321722

you can set the expires header to be -1 and this fixes the problem:

if(strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE 6.') !== false)
{
header('Cache-Control: no-cache');
header('Expires: -1');
}

http://uk3.php.net/manual/en/function.header.php#88875
http://support.microsoft.com/kb/234067/en-us

Comment #47

PixelClever commented 2 June 2009 at 21:22

Title:

Normal caching mode causes white screen for IE6 (pre SP2)

» Normal caching mode causes white screen for IE6

Removing (pre SP2) from title as this happens on post sp2 versions as well.

Comment #48

catch

he/him

English

commented 4 December 2009 at 16:27

Priority:

Critical

» Normal

IE6 != critical.

Comment #49

Lucasljj commented 8 September 2015 at 01:28

Status:

Needs work

» Closed (won't fix)

Drupal 7 require Internet Explorer 8.x and later, see https://www.drupal.org/node/61509

Comment #50

David_Rothstein commented 7 October 2015 at 19:31

Priority:	Normal	» Minor
Status:	Closed (won't fix)	» Needs work

That page was misleading (and looks like it since has been fixed). We haven't officially dropped support for IE6 in Drupal 7. Certainly these issues are very low priority now, but if someone wants to fix them and can do it in a way that doesn't hurt other browsers, it's still possible to do so.

Comment #51

7 October 2015 at 19:31

Status:

Needs work

» Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.