Normal caching mode causes white screen for IE6 (pre SP2)
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | patch (code needs work) |
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
<?php
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 GMTHTTP/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=18016HTTP/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
#1
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.
#2
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!
#3
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!
#4
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.
#5
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.
#6
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
#7
I have tested it more. It does work when a user has logged on, not for the visitors.
#8
After patching the first post's changes. Just to describe it better:
Initial request (headers):
GET /el HTTP/1.1Accept: 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 OKDate: 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.1Accept: */*
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 OKDate: 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.1Accept: */*
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 ModifiedDate: 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
#9
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.
#10
Finally it was solved after disabling module clickpath. I do not know why, but now it works.
#11
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
:-)
#12
A real patch would be nice. :-) http://drupal.org/patch/create
#13
subscribing
#14
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.
#15
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!
#16
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..
#17
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
#18
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 :-)
#19
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.
#20
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....
#21
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.
#22
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.
#23
subscribe
#24
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
#25
Looks like I was missing an end bracket. thanks.
#26
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?
#27
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.
#28
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.
#29
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...
#30
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.
#31
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.
#32
Personally, I'm not a big fan of browser specific hacks.
#33
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.
#34
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.
#35
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.
#36
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.
#37
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...
#38
#39
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.
#40
Thanks for the help, can you tell me exactly what/where I should paste please so I can try it out?
#41
If you look at the last bit of the patch you will see this:
<?phpif (((@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:
<?php
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));
}
?>
#42
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
#43
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?