After enabling h2 between haproxy and our backend servers we sometimes notice that haproxy sends an RST_STREAM immediately after the HEADERS packet with the GET request. I've logged the packages and in this case less than 3 ms after haproxy sends GET, haproxy then sends an RST_STREAM.
Time (seconds) source destination Protocol Packet 69.632322 haproxy -> backend HTTP2 HEADERS[25]: GET /image.svg 69.635099 haproxy -> backend HTTP2 RST_STREAM[25] What could be the cause of that? The stream gets closed before the backend can write the response. First I suspected this was due to e.g. end user closing their browser or similar. But it occurs a bit too often for that and we have also got reports of missing images from end users. We are using haproxy 3.0.5. Any ideas what I can look into or is this normal? I can also see a bunch of WINDOW_UPDATE packages sent very frequently by haproxy, maybe that is expected and unrelated? 8.915556 haproxy -> backend HTTP2 WINDOW_UPDATE[127], WINDOW_UPDATE[0] 8.915594 haproxy -> backend HTTP2 WINDOW_UPDATE[127], WINDOW_UPDATE[0] 8.916445 haproxy -> backend HTTP2 WINDOW_UPDATE[127], WINDOW_UPDATE[0] 8.916487 haproxy -> backend HTTP2 WINDOW_UPDATE[127], WINDOW_UPDATE[0] 8.917168 haproxy -> backend HTTP2 WINDOW_UPDATE[127], WINDOW_UPDATE[0] 8.917220 haproxy -> backend HTTP2 WINDOW_UPDATE[127], WINDOW_UPDATE[0] 8.918075 haproxy -> backend HTTP2 WINDOW_UPDATE[127], WINDOW_UPDATE[0] This is the config we use for the backend: backend bk_appsrv mode http balance roundrobin option httpchk http-check connect proto h2 http-check send meth GET uri /status ver HTTP/2 http-check expect rstatus 200 cookie shtick insert indirect nocache secure server server1 server1:80 cookie appbfy1 check maxconn 512 proto h2 server server2 server2:80 cookie appbfy2 check maxconn 512 proto h2 /Andreas
