- Using the option zlib.output_compression results in a garbled browser content because the Content-Encoding: zlib header is not sent (but the content is correctly compressed).
- Using ob_start ('ob_gzhandler') does work (=> zlib is installed right, not a browser problem)
- Adding a Header ('Content-Encoding: zlib') does work for the page itself but fails for images (phpinfo () does show text but no images)
The problem seems to be that the zlib is not build with together with the apache module. There is #ifdef HAVE_ZLIB in the main/SAPI.c that writes the Content-Encoding header.
To solve the problem I did add the line 'CONFIGURE_ARGS+= --with-zlib=/usr --with-zlib-dir=/usr' to the www/mod_php5/Makefile. This solves the problem (but bundles the zlib extension).
How-To-Repeat: In FreeBSD 5.3
Install apache 1.3 + mod_php5 + mod_zlib and edit php.ini to set zlib.output_compression=On
Over to maintainer of archivers/php5-zlib, which, as best I can tell,
this PR is about.
Adding to audit trail from misfiled PRs 79867 and 79871. Note to
submitter: sending patches via quoted-printable utterly destroys them.
Date: Wed, 13 Apr 2005 18:29:22 +0300
Vasil Dimov wrote:
> What happens is that
> zend_ini_long("zlib.output_compression", sizeof("zlib.output_compression"), 0)
> is always false when zlib is not loaded even if zlib.output_compression
> is turned on in php.ini and so - no extra headers or errors appear when
> zlib.output_compression=On and no zlib.so extension is loaded.
Good catch! I'll try it asap and if it is really so I'll commit it. PHP
devs claimed for years that this was an unsolvable issue in php4 ;-)