Page MenuHomePhabricator

Enabling zlib.output_compression results in wrong Content-Length
Closed, ResolvedPublic

Description

Introduced in D12622

Connection hangs until timeout while trying to read such files.

curl -v 'https://phabricator/res/defaultX/phabricator/e18bf0da/core.pkg.css' -H 'Accept-Encoding: gzip, deflate, sdch, br'  --compressed > /dev/null
...
< Content-Length: 271871
< Connection: keep-alive
<
{ [15716 bytes data]
 37  265k   37   99k    0     0   1676      0  0:02:42  0:01:00  0:01:42     0* transfer closed with 170238 bytes remaining to read
 37  265k   37   99k    0     0   1673      0  0:02:42  0:01:00  0:01:42     0
* Closing connection 0
curl: (18) transfer closed with 170238 bytes remaining to read...

==> /var/log/nginx/phabricator.access.log <==
[13/Dec/2016:20:45:17 +0000] "GET /res/defaultX/phabricator/e18bf0da/core.pkg.css HTTP/1.1" 200 duration=0.573 101633 "-" "curl/7.49.1"

With this line commented length is correct:

< Content-Length: 271871
...

==> /var/log/nginx/phabricator.access.log <==
[13/Dec/2016:20:41:10 +0000] "GET /res/defaultX/phabricator/e18bf0da/core.pkg.css HTTP/1.1" 200 duration=0.065 271871 "-" "curl/7.49.1"

Event Timeline

I can see this too with an unknown version of Apache (Probably 2.2.15) over HTTPS, PHP 5.3.3 (built: Aug 11 2016 17:13:57) (w/o explicitly setting the header) :

curl -v 'https://..../res/defaultX/phabricator/e18bf0da/core.pkg.css'  --compressed > /dev/null
...
curl: (18) transfer closed with 170238 bytes remaining to read

Trying it locally, with apache 2.4.7 and php 5.5.9 over HTTP, it appears I'm just not getting the Content-Length header, so curl isn't confused.

What versions of apache/php/php-fpm are you using, @pzinovkin?

I wasn't able to reproduce any hangs or bad behavior from curl locally, but I think D17045 should cause us to select either compression or Content-Length, which is a reasonable thing to expect us to do.

Using Chrome's network tab + disable cache, loading a page from the effected system shows that some rsrc requests take 55s each, during which chrome is "loading". Since they're static resources, I guess it's hard to notice when cache is on. Also, I don't think secure-dot is effected.

I think this is fixed now -- let us know if you're still seeing issues. Thanks for the very thorough report!

I think this compression had messed up with HTTP served Git repository. Git complains with

fatal: https://abc.com/diffusion/P/xxx.git/info/refs not valid: is this a git repository?`

Adding fastcgi_param HTTP_ACCEPT_ENCODING ""; to Nginx config would fix this problem. I've also tried to comment out the zlib.output_compression part in aphront/response/AphrontResponse.php. It works too.

Please file a new task following the instructions in Contributing Bug Reports if you'd like us to take a look. We need all that information before we can start looking at a bug.