Le 28/11/2018 à 04:37, Willy Tarreau a écrit :
Hi Veiko,
On Mon, Nov 26, 2018 at 07:59:50PM +0000, Veiko Kukk wrote:
Hi!
There is not much to add, just that it's been broken before in 1.7.9 and is
again broken in 1.7.11. Works with 1.7.10.
When applying patch provided here
https://www.mail-archive.com/[email protected]/msg27155.html 1.7.11 also
works.
Testing is really simple, just configure haproxy gzip compression and
download with curl --compression or with web browser. Sample .js file I have
downloaded has real size 42202 bytes but when downloading with gzip
compression, it's size is 37648 bytes - part of the end is missing.
Very similar issue is discussed here too
https://discourse.haproxy.org/t/1-7-11-compression-issue-parsing-errors-on-response/2542
Interesting, this patch was indeed never merged but a slightly different
one with the exact same date and a slightly different description was
merged instead. Thus I'm CCing Christopher to get his opinion on this.
We likely have to merge it all the way back to 1.7, but I want to be
extra careful.
Thank you very much for the report and for testing the patch!
Hi Veiko,
Sorry for my late reply. I'm pretty busy to finish my dev on the 1.9 for
now. As Willy said, the patch you mentioned was updated before the merge.
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.
So there is definitely a bug. And for the following days, it will be
hard for me to really work on it. In the mean time, could you share
HAProxy logs of the faulty response, the minimal configuration to
reproduce the bug and get the request/response headers from the client
point of view and from the server one ? Could you also provide a network
capture of the bad response between HAProxy and your server and between
the client and HAPRoxy ? In addition, you may also try to add 2 trace
filters, before and after the compression with this kind of configuration:
frontend ...
...
filter trace name BEFORE
filter compression
filter trace name AFTER
...
You must start HAProxy in foreground to get trace messages. Be careful,
the trace filter is pretty verbose. Don't forget to anonymize the
outputs removing sensitive information (ip, hostname...), 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 ?
Sorry to ask you so much work but I'm on a dead end for now. And this
kind of bug a still pretty hard to reproduce. :)
Thanks !
--
Christopher Faulet
