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.
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)
Regards,
Veiko
