Hi Lukas, On Fri, Dec 29, 2017 at 11:45:55AM +0100, Lukas Tribus wrote: > On Fri, Dec 29, 2017 at 11:22 AM, Lukas Tribus <lu...@ltri.eu> wrote: > > It's that: > > - when sending the POST request to the backend server, haproxy sends a > > FIN before the server responds > > - nginx doesn't like that and closes the request (you will see nginx > > error code 499 in nginx server logs) > > - as there is a race on the backend server between receiving the FIN > > and completing the response, this does not always happen > > - haproxy returns "400 Bad Request" to the client, although the > > request is fine and the response was empty (I consider this a bug) > > > > > > The feature on nginx is basically what we call abortonclose, and can > > be disabled by the following nginx directives (depending which backend > > modules is used): > > http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort > > http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_ignore_client_abort > > > > > > Howto reproduce the haproxy behavior: > > - have a http backend pointing to nc > > - make a POST request > > - this is even reproducible with H1 clients, however H2 has to be > > enabled on haproxy otherwise it doesn't send the FIN (strangely > > enough) > > > > > > Does this make sense? > > The FIN behavior comes from a48c141f4 ("BUG/MAJOR: connection: refine > the situations where we don't send shutw()"), which also hit 1.8.2, so > that explains the change in behavior between 1.8.1 and 1.8.2.
That's very nice, thanks for the detailed info. So we're indeed still fighting with some of the stuff inherited from H1 that is hard to reproduce without H2. I've made a lot of tests with nc as a server, others as well with thttpd and a CGI. I couldn't observe this phenomenon anymore, but I'll recheck. I remember having played with certain areas in the code that looked suspicious to me but which didn't appear to improve anything so I refrained from taking the risk to break even more. Maybe this needs to be revisited. I'll take all of you updated regarding this. BTW, I've updated haproxy.org to 1.8-latest and am seeing a much higher ratio of HTTP/2 in the logs (~50%). Thus it seems that lack of ALPN was definitely the reason for it being so limited. I anticipated that it could be the case when deploying it but since I immediately received some traffic, I considered that it was apparently not an issue (and I was wrong). Cheers, Willy
