应用程序的输出应该只包含一个输出编码.如果您有多个编码方式不同的块,那么浏览器将得到一个无法使用的结果.因此编码错误.
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;
并确保在此之后您没有任何更多输出.
如果您将PHP到达脚本的末尾,它将会处理:刷新和输出.
现在你需要手动调用ob_flush()来显式地让PHP通过回调推送缓冲区.
用Curl检查HTTP压缩问题
由于firefox将返回错误,因此需要另一个检查导致编码错误的工具.您可以使用curl跟踪发生的情况:
curl --compress -i URL
在显示所有响应标头和未编码的主体时,将请求启用压缩的URL.这是必要的,因为PHP透明地启用/禁用基于请求标头的ob_gzhandler回调压缩.
响应还表明PHP也将设置所需的响应头.因此无需手动指定它们.这甚至是危险的,因为只有通过调用ob_start(‘ob_gzhandler’),你才能说压缩是否被启用.
如果压缩被破坏,curl将给出错误描述,但不会显示正文.
以下是由错误的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
这可以给人一种出错的印象,比如体内未压缩的部位.