Hi Maximilian,
On Tue, Mar 19, 2019 at 01:17:52PM +0000, Maximilian Böhm wrote:
> 172.17.0.1:46372 [19/Mar/2019:12:10:43.465] [fntnd] [bknd] 0/0/0/-1/8 400 187
> - - CH-- 1/1/0/0/0 0/0 "POST [URL] HTTP/1.1"
This one could indicate a client close while uploading the contents, but
it could also actually be a side effect of the ambiguity we have at
certain stages between an end of request and a close, and the short
timings make me think about this.
> Any ideas? Maybe a similar bug is known?
Not directly known but could be related to something we're currently
working on as indicated above.
> What shall/can I do next? Setting up
> Wireshark with MITM and comparing the requests? Right now, I can't imagine
> the error is on side of the client nor on the backend (the backend is not
> changed).
There are two things you can try :
1) please issue "show errors" on your CLI when this happens, to see if
you find a real client error captured there. It could be possible that
something is invalid in the request and that it was blocked during the
parsing (though quite unlikely).
2) you can enable the HTX mode which avoids the translation from H2 to H1
before processing the request. For this, please add "option http-use-htx"
to your configuration and see if the problem goes away or becomes more
frequent (or doesn't change). In all cases please report your observation
here :-)
> The bug happens on our productive cluster as well as in a docker container
> ("haproxy:1.9.4"). I was able to reproduce the same bag within that container
> with a minimal configuration (see below).
At first glance your config is perfectly fine, so it could very well be
related to the issue above.
Thanks!
Willy
