Hi Veiko,
On Wed, Dec 05, 2018 at 03:49:24PM +0000, Veiko Kukk wrote:
> On 2018-11-30 09:40, Christopher Faulet wrote:
>
> > Now, I'm still puzzled with this issue. Because I can't reproduce it
> > for now. And it is even more strange because when the compression is
> > enabled and used on a response, it cannot be switched in TUNNEL mode.
> > So I don't really understand how the patch you mentioned could fix a
> > compression bug, or the commit 8066ccd39 (as stated on discourse)
> > could be the origin of the bug.
>
> I've found that 'option http-server-close' in frontend is causing this.
> Commenting it out and 1.7.11 is working fine with gzip compression.
>
> I'm not gathering more debug data at the moment, maybe this already helps to
> reproduce the issue. I will provide more if necessary.
This is already quite helpful, thank you for these details.
> > Finally, I have a last question. You said the result is truncated. It
> > means the response is truncated because of a close and not all chunks
> > are received ? Or the response is correct from the HTTP point of view,
> > but the file is truncated once uncompressed ?
>
> Uncompressed file is truncated, part of it at the end is missing.
> Not sure what do you mean by correctness from HTTP point of view, but the
> headers look fine.
>
> > GET /assets/js/piwik.js?v=1534 HTTP/1.1
> > Host: foobar.tld
> > User-Agent: curl/7.61.1
> > Accept: */*
> > Accept-Encoding: deflate, gzip, br
> >
> { [5 bytes data]
> < HTTP/1.1 200 OK
> < Date: Wed, 05 Dec 2018 15:45:26 GMT
> < Content-Encoding: gzip
> < Content-Language: en
> < Content-Location: http://foobar.tld/assets/js/piwik.js?v=1534
> < Content-Type: application/x-javascript; charset=UTF-8
> < Expires: Sat, 02 Dec 2028 15:45:26 GMT
> < Last-Modified: Fri, 23 Nov 2018 15:51:00 GMT
> < Cache-Control: max-age=315360000
> < Date: Wed, 05 Dec 2018 15:45:26 GMT
> < Accept-Ranges: bytes
> < Server: Restlet-Framework/2.3.9
> < Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
> < Connection: close
>
> 65236 Dec 5 16:29 piwik.js (without option http-server-close)
> 41440 Dec 5 17:45 piwik.js_ (with option http-server-close)
OK so it looks like the last block is missing. Maybe we lose these
contents when closing the server's connection. Also it's useful to
see that it happens on small files, I expected that it would only
fail on very large ones when the output buffer is full, and it's
not the case here.
I must confess that most of the people able to look closer to
this are currently busy trying to finalize 1.9 for an imminent
release, so we'll have to postpone this debugging a little bit.
In the mean time it would be useful to see if adding
"option http-pretend-keepalive" helps. This way we'll know if
it's the server closing first or haproxy closing first which
triggers this. And if it turns out that it fixes the issue for
you, it could be a good temporary workaround.
Cheers,
Willy
