Le 21/11/2019 à 23:54, Valters Jansons a écrit :
Hello everyone,

I am running HAProxy v2.0.9 on Ubuntu using the dedicated PPA 
(ppa:vbernat/haproxy-2.0). There seems to be a behavior change for a specific 
endpoint between HTX enabled and HTX disabled, but I have not been able to 
pin-point the exact root cause.

With HTX disabled (`no option http-use-htx`), a browser makes a POST request 
(ALPN H2) which is shown as HTTP/1.1. That then reaches the backend (IIS) as 
HTTP/1.1 and finishes successfully in around 10 seconds.

With the default behavior of HTX enabled, the POST request comes in and is 
shown as HTTP/2.0. It then connects to backend as HTTP/1.1 and the client 
receives a 200 OK and the response data around the same time as without HTX. 
However, the connection does not get properly closed until server timeout with 
a termination_state of sD-- (server-side timeout in the DATA phase). At that 
point, debug log shows `srvcls` and the client connection is 'successfully' 
closed. The backend itself seems to think it handled the request 'as usual'.

The non-HTX debug log does not show srvcls, clicls and closed events on the 
backend whatsoever, but seeing as that connection does terminate, I am guessing 
the relevant events just don't get logged with HTX disabled.

We are using http-keep-alive as the default connection mode, but changing it to 
http-server-close or httpclose does not seem to make a difference.

The strange part here is that we are seeing this particular behavior with HTX 
enabled only on browsers (tested Chrome and Firefox on multiple machines), as 
testing using cURL (H2) or simply via OpenSSL's s_client (HTTP/1.1) appears to 
work even when HTX is enabled, and additionally, we are seeing this on the 
particular endpoint only for a specific user's context. That could also imply 
that it has something to do with the response data, or maybe it could just be a 
red herring. Maybe HTX is waiting on some trailing headers or some other 
feature of HTTP..

Any ideas as to where I should start troubleshooting HTX behavior for one 
production endpoint for one specific user context?


Hi,

Could you share your configuration please ? If it only happens on a specific endpoint, you can remove configuration of the others. Then if it is easily reproducible, you may try to find the minimal config to do so. Finally a network capture on a server side may help too (share it privately).

In the mean time, could you describe your request and your response when the problem occurs (size, chunked-encoding Vs content-length, compression ...) ? And from the browser point of view, is there any difference with and without the HTX ?

If possible, could you try disabling the h2 on the frontend side ? It could help to identify where the problem is.

Finally, have you already tested other 2.X versions without encountering the problem?

Thanks,
--
Christopher Faulet

Reply via email to