Problems with cache and zlib.output_compression
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | duplicate |
I did some searches on the older issues on this, people reporting problems with PHP giving "gzinflate data error", or pages being blank. I ran into this exact problem myself with a fresh installation of Drupal 5.3, when I enabled caching. The core of the problem seems to be two folded:
1) I suspect there's a misunderstanding in what the result from ob_get_contents() is. As far as I can tell, it's never gzip encoded, so in the current 5.3 code, the cache can be either plain-text or "gzip" compressed, depending on what the first request was.
2) If the site has enabled zlib.output_compression in a php.ini, once the cached object is actually gzip encoded, you end up serving pages which are compressed twice.
I spent a little time on this, and with the help of Brian France, came up with the attached patch. This seems to work on my various setups and tests with zlib.output_compression turned on and off, and the first (cache miss) being either AE: gzip or not.
It's also unclear to me how this cache compression code would interact with mod_deflate or other apache modules that would compress the output as well. But I can look into that if there's interest in this.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| cache.diff | 1.36 KB | Ignored | None | None |
#1
I had the same problem, i had setup my php.ini to use as output_handler = ob_gzhandler.
But when you enable the cache, we don't check if the data are handled by ob_gzhandler or zlib.output_compression.
So we must also check about this.
I fount it somehow implemented here : http://groups.google.com/group/k2svn/browse_thread/thread/46957642a2b7fdcb
I change it a little bit, actually some stylish corrections and we are ready to go.
Please review the patch.
#2
Anything, which we can modify runtime in the PHP settings to our needs, we should do IMHO, instead of checking for the settings.
#3
The first patch follows Gábor's suggestion of modifying incompatible PHP configurations, in addition to workarounds when modification might not take hold. It also fixes the correct line of code.
The second looks more thorough for checking all possibilities, but I am a bit wary of such a large if condition. 'or' should be '||' and 'false' should be 'FALSE' to work with our code style conventions. It looks like it turns caching completely off instead of preventing double compression.
#4
subscribing. This ain't fixed in drupal 5.7.
#5
subscribe
#6
but is it fixed in the latest version, 5.10?
#7
no, I have 5.10
#8
This has been very difficult to reproduce and is on my list of least favorite bugs ever. Adding
ini_set('zlib.output_compression', 0);to bootstrap.inc fixes it for browsers that freak out.<?php// 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.
ini_set('zlib.output_compression', 0);
$cache->data = gzinflate(substr(substr($cache->data, 10), 0, -8));
}
elseif (function_exists('gzencode')) {
header('Content-Encoding: gzip');
}
?>
#9
This could be related:
#43462: cache_set and cache_get base_url brokenosity
#10
Looks like a duplicate.
#11
Definitely related. Thanks!