HHVM FastCGI上的Content-Length标头是间歇性的

Question

Maybe it's the jetlag, but I'm failing to make PHP/HHVM give me the Content-Type header when I need it.

I've deployed the full stack (MySQL, HHVM, Nginx) on a Vagrant machine and I've managed to reproduce the issue on a test script:

<?php
$file='/usr/share/doc/iptables/html/NAT-HOWTO.html'; # random test file
header('Content-Length: ' . filesize($file));
echo(readfile($file));
?>

If you examine the headers with curl:

hostname:~ jsimpson$ curl -I http://vagrant/test.php
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 16 Sep 2014 22:09:25 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2592
Connection: keep-alive
X-Powered-By: HHVM/3.2.0
Content-Encoding: none;

We have a content length header. However if we hit the same URL from Chrome, and get the headers from the Dev tools:

HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 16 Sep 2014 22:14:41 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: HHVM/3.2.0
Content-Encoding: gzip

No Content-Length header. I've also packet sniffed this to verify that the header isn't sent. I can switch to PHP FPM and it sends the header.

Answer 1

I reproduced the issue by hitting the server with:

curl -H 'Accept-Encoding: gzip,deflate' --compressed -v http://foo/bar

HHVM enables compression by default. Disabling that gave me the header back.

Everything was awesome after adding this to /etc/hhvm/server.ini

hhvm.server.gzip_compression_level = 0

Answer 2

I stumbled upon this issue/feature. Not running HHVM though. Pure nginx + PHP-FPM. The thing is, if your PHP app calculates and sets Content-Lenght header field, and your nginx is configured to gzip content, it will just ditch this information and replace it by Chunked transfer encoding and GZIP headers. So do not set GZIP to a very small buffers, default is 20 bytes which does quite the opposite (end result is larger then before GZIP compression). I set it like this: gzip_min_length 1024;