Hello,
On Fri, Dec 29, 2017 at 8:13 AM, Willy Tarreau <[email protected]> wrote: > Yep. For what it's worth, it's been enabled for about one month on haproxy.org > and till now we didn't get any bad report, which is pretty encouraging. It appears to run 1.7.5 though: http://demo.haproxy.org/ >> For now, I'll personally leave http2 support disabled - since it's breaking >> my applications for a big percentage of my users, and I'll have to find an >> intermediate solution until at least the bug in regards to Firefox losing >> connections (this thing): >> >> Dec 28 21:22:35 localhost haproxy[1534]: 80.61.160.xxx:64921 >> [28/Dec/2017:21:22:12.309] https_frontend~ https_frontend/<NOSRV> >> -1/-1/-1/-1/22978 400 0 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>" >> Dec 28 21:22:40 localhost haproxy[1534]: 80.61.160.xxx:64972 >> [28/Dec/2017:21:22:35.329] https_frontend~ cdn-backend/mycdn 0/0/1/0/5001 >> 200 995 - - ---- 1/1/0/1/0 0/0 "GET /js/app.js?v=1 HTTP/1.1" > > If this is met in production it definitely is a problem that we have to > address. Could you please try the attached patch to see if it fixes the > issue for you ? If so, I would at least like that we can keep some > statistics on it, and maybe even condition it. I've been able to pinpoint the POST issue affecting 20% of the requests. It has nothing to do with connection headers, invalid requests or browsers. 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? cheers, lukas
