> Lucas, can you check my previous mail and see if you can enable ignoring
> client aborts in your backend, assuming you are using nginx?
I can confirm that ignoring client aborts in my backend using
fastcgi_ignore_client_abort “resolves” the issue regarding POST requests.
Best Regards,
Lucas R
On 29/12/2017, 11.46, "lu...@ltri.eu on behalf of Lukas Tribus" <lu...@ltri.eu>
wrote:
Hello,
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.
Lucas, can you check my previous mail and see if you can enable
ignoring client aborts in your backend, assuming you are using nginx?
Thanks,
Lukas
