Wiki source for DetectingZlibOutputCompression

Show raw source

=====How to detect automatically if zlib.output_compression is set?=====
Wikka has a problem when zlib.output_compression is set. This is a simple technique to make wikka compatible and requires no action from administrator when the server environment changes :
$zlib_OC_is_set = eregi('On|(^[0-9]+$)', ini_get('zlib_output_compression'));

Then add a condition %%(php)(&& (!$zlib_OC_is_set))%% when testing if $_SERVER['HTTP_ACCEPT_ENCODING'] allows gzip content encoding.
The PHP manual [[ | suggests the using of ZLib library]] is preferable to using ob_gzhandler. Now, I have no idea why one is preferable to the other (speed?, but then how widespread is zlib module in PHP installs for e.g.?), so I ask if anyone knows why. If a user has zlib installed, then another alternative is to use .htaccess:

%%<FilesMatch "\.(php|html?)$">
php_value zlib.output_compression 4096

Also - what is the bug you are fixing here - any is it specific to Wikka, or a general bug? Is is browser dependant? I've used zlib.output_compression with wakka for ages without a problem. Thanks for any info! --IanAndolina

~&The use of output compression is a Wikka enhancement, and is absent in Wakka. That's why you had no problem with Wakka. This bug is seen in [[LetterSaladOutputWorkaround]], and is specific to Wikka. --DotMG
~~&OK, I just found [[ | this comment]] explaining the difference. Basically it is simply to do with the fact that zlib.output_compression works in parallel with the script. BUT because we use ob_start() anyway, there is thus no difference between the two as I see it (and zlib.output_compression can be set on a per file basis as the later [[ | comments]]). If output buffering was ever turned off, then zlib.output_compression seems preferable. I did use zlib.output_compression with wakka without problems BTW, using the simple .htaccess method... --IanAndolina

Valid XHTML :: Valid CSS: :: Powered by WikkaWiki