[drupal-support] PHP compression and cacheing
I think there's a possible problem with PHP zlib.output_compression = on and Drupal caching. I have zlib.output_compression = on in php.ini on the server. I've seen a couple of instances where setting drupal output caching to enabled resulted in either blank pages coming back or random ascii text as though the output was being double encoded. Does this ring any bells? Setting caching off always seems to cure it. -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/
Julian Bond wrote:
I think there's a possible problem with PHP zlib.output_compression = on and Drupal caching. I have zlib.output_compression = on in php.ini on the server. I've seen a couple of instances where setting drupal output caching to enabled resulted in either blank pages coming back or random ascii text as though the output was being double encoded. Does this ring any bells? Setting caching off always seems to cure it.
This rings a bell -- alas Moshe reported a similar issue. To date, we haven't been able to reproduce nor fix it. From what I have been told, it is specific to IE <some-version>. More details or investigation would be appreciated. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert <dries@buytaert.net> Tue, 1 Mar 2005 14:12:38
This rings a bell -- alas Moshe reported a similar issue. To date, we haven't been able to reproduce nor fix it. From what I have been told, it is specific to IE <some-version>. More details or investigation would be appreciated.
Just been looking through bootstrap.inc. - Page data retrieved via ob_get_contents() - Page data is gzencoded - gzencoded string saved in table cache - New request arrives - If the browser doesn't support gzip, inflate it. Else leave it gzipped. - If it's still gzipped send content encoding header - print the results. Now if I have php doing gzip via zlib.output_compression in php.ini, that last print is going to be gzip encoded again. *Unless* php recognises that the code has already set the content encoding header and so passes it through untouched. So what we could have here is:- 1) A bug in php handling that is missing the fact that the code is saying I've already encoded it resulting in double encoding. 2) some combination of the browser saying it can accept gzip, deflate when actually it can only accept deflate. 3) Some browsers managing to work out, some times, that a file is double encoding and decoding it until they see an <html> statement. I think I'd recommend leaving everything in plain and letting php (zlib.output_compression) or apache (mod_gzip) do the negotiation with the browser. Alternatively add an administration switch to enable/disable buffering and gzencoding of all output for people who don't have access to php.ini or apache. Or a third possibility, put the php switch into the .htaccess file. At the moment I think there's at least a possibility of double encoding happening. -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/
This rings a bell -- alas Moshe reported a similar issue. To date, we haven't been able to reproduce nor fix it. From what I have been told, it is specific to IE <some-version>. More details or investigation would be appreciated.
I have faced it with Firefox 1.0. The problem goes when you point to any other url, for example /glossary, then back to the homepage and it loads perfectly. Regards maykel
Maykel Moya wrote:
This rings a bell -- alas Moshe reported a similar issue. To date, we haven't been able to reproduce nor fix it. From what I have been told, it is specific to IE <some-version>. More details or investigation would be appreciated.
I have faced it with Firefox 1.0. The problem goes when you point to any other url, for example /glossary, then back to the homepage and it loads perfectly.
One way to solve this is to add an extra 'Cache setting' that lets us enable/disable compression. -- Dries Buytaert :: http://www.buytaert.net/
I've done some further testing on this. Apache/2.0.52 (Win32) mod_perl/1.99_12 Perl/v5.8.2 PHP/4.3.4, Turck's mmCache running on Win XP SP2 Start with zlib.output_compression = off in php.ini Drupal cache off Logout Firefox and IE6 work fine. Now turn Drupal cache on and log out All pages display in both firefox and IE6. Pages can be seen to be cached in the dbms. Using the firefox live http headers extension you can see either the 304 unmodified or Content-Encoding: gzip headers. What may be missing is the Vary: Accept-Encoding header Now switch zlib.output_compression = on in php.ini and restart apache new pages display fine in firefox and IE6. Cached pages display as binary in firefox and throw an error in IE6 "unknown content type". New pages are served with no gzip. Cached pages are either 304 or show Content-Encoding: gzip. Now get back to a page that is fresh so you can login. login and turn Drupal cache off. All pages now display fine in both Firefox and IE6. Returned headers show Content-Encoding: gzip Vary: Accept-Encoding As a final test I went into bootstrap.inc and in drupal_page_header() I commented out the line header('Content-Encoding: gzip'); and changed the browser gzip check so it always inflated the cached data and everything worked fine with cache enabled and php set to compress. So it looks pretty clear to me that Drupal should not be attempting to gzip encode the returned cache page if php or apache is also gzip encoding everything. I don't really see the benefit of storing the cached data gzip encoded as even on vast site, there's not going to be that much html. The short term solution is just to always inflate the cached page before the print statement. The longer term solution is to provide an admin switch so that people without access to php.ini, .htaccess and so on, can choose. And/or test for zlib_get_coding_type()=='gzip' to see whether it's turned on and take appropriate action. However this last will not find mod_gzip if that's installed in apache. Here's one way of doing it. Around line 262 of bootstrap.inc // Determine if the browser accepts gzipped data. if ( zlib_get_coding_type() == 'gzip' || (@strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') === false && function_exists('gzencode')) ) { -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/
On Tue, 1 Mar 2005, Julian Bond wrote:
I think there's a possible problem with PHP zlib.output_compression = on and Drupal caching.
There have been reports that stated this, yes.
I have zlib.output_compression = on in php.ini on the server. I've seen a couple of instances where setting drupal output caching to enabled resulted in either blank pages coming back or random ascii text as though the output was being double encoded.
Can you describe under which circumstances ths might happen? Does this happen always if a page is cached?
Does this ring any bells? Setting caching off always seems to cure it.
I am of the opinion that Drupal sets the right header and zlib.output_compression should not compress the cached pages again. Apparently zlib does not agree or doesn't read headers. A possible fix would be not to store gzipped pages if zlib compression is used. Cheers, Gerhard
participants (4)
-
Dries Buytaert -
Gerhard Killesreiter -
Julian Bond -
Maykel Moya