在代码中,如果echo $gz;被注释掉我没有收到错误(但也没有输出！),如果不是我得到的(来自Firefox),
Content Encoding Error
The page you
are trying to view cannot be shown
because it uses an invalid or
unsupported form of compression.
感谢您的帮助,以下是代码：
ob_start('ob_gzhandler') OR ob_start();
echo 'eh?';
$gz = ob_get_clean();
echo $gz;
Kohana本身已经使用了输出缓冲区.如果你想将它与你的ob_gzhandler输出缓冲区结合起来,你需要在kohana初始化它之前启动你的缓冲区.那是因为输出缓冲区是可堆叠的.当kohana完成输出缓冲后,您的申请将适用：
ob_start('ob_gzhandler'); # your buffer:
ob_starts and ends by kohana
因此,每当kohana完成一些输出时,这些块将被传递到输出回调(ob_gzhandler())并将进行gz编码.
然后,浏览器应该只获取gz编码的数据,因为它是最顶层的输出缓冲区.
使用ob_gzhandler并手动回显缓冲区
如果你使用ob_start(‘ob_gzhandler’)让PHP处理压缩,然后你回显ob_get_clean(),你将创建一个不可靠的输出.这与压缩与输出缓冲的工作方式有关：
PHP将缓冲输出块.这意味着,PHP开始压缩输出但保留一些字节以继续压缩.所以ob_get_clean()返回缓冲区的远程压缩部分.通常这个结果并不完整.
要处理它,首先刷新缓冲区：
ob_start('ob_gzhandler') OR ob_start();
echo 'eh?';
ob_flush();
$gz = ob_get_clean();
echo $gz;
并确保在此之后您没有任何更多输出.
现在你需要手动调用ob_flush()来显式地让PHP通过回调推送缓冲区.
用Curl检查HTTP压缩问题
由于firefox将返回错误,因此需要另一个检查导致编码错误的工具.您可以使用curl跟踪发生的情况：
curl --compress -i URL
在显示所有响应标头和未编码的主体时,将请求启用压缩的URL.这是必要的,因为PHP透明地启用/禁用基于请求标头的ob_gzhandler回调压缩.
响应还表明PHP也将设置所需的响应头.因此无需手动指定它们.这甚至是危险的,因为只有通过调用ob_start(‘ob_gzhandler’),你才能说压缩是否被启用.
以下是由错误的PHP脚本引发的不完全生成的输出引起的卷曲错误消息：
HTTP/1.1 200 OK X-Powered-By: PHP/5.3.6 Content-Encoding: gzip ... curl: (23) Error while processing content unencoding: invalid code lengths set
通过添加–raw开关,您甚至可以进入原始响应体：
curl --compress --raw -i URL
这可以给人一种出错的印象,比如体内未压缩的部位.
