Haproxy with cookies ~5k fails

Hi, wondering if anyone can shed some light on something I observed over the last few days while testing H2 on haproxy 1.8, 2.0 ,2.2 and 2.3. I ended up with a number of fe,be configurations trying out different scenarios, however tested them all respectively against each version mentioned.

The test was a curl agent with the same request going in a fe out to the same be. The be was an nginx ingress controller with mostly default config and the request contained a ~5k (oauth) cookie, this cookie was causing the issue. If I went a byte >4096 the connection crashed out. This got resolved on the ingress controller and as far as I can see isn’t a bug with haproxy, however I can’t be sure because I wouldn’t expect the results below.

Long story short, out of all of the configurations I had where h2 is enabled on the backend regardless of fe config the request fails into a retry loop and eventually bombs out across all haproxy versions. I managed to fix this but I don’t understand how haproxy as a client was susceptible to it. I tried 3 different version of curl in the testing process.

direct
curl force h1 -> ingress controller <- return 302
curl force h2 -> ingress controller <- return 302
curl h1 -> upgraded to h2 ingress controller <- return 302

via haproxy version stated above
curl h1 -> haproxy force h1 be <- return 302 (no h2 configured)
curl h1 -> haproxy -> upgraded to h2 at ingress controller <- return 302
(h1 on fe, automatically upgraded without config to enforce otherwise)
curl h2 -> haproxy -> upgraded to h2 at ingress controller <- return 302
(h2 on fe, automatically upgraded at be without config to enforce otherwise)
curl h1 -> haproxy force h2 <- fail
curl h2 -> haproxy force h2 <- fail

Going direct no issue, letting the connection upgrade from h1 to h2 no issue. However h2 forced on the be immediate enter a retry loop and crash after 5.

So adding “http2-max-field-size: 8k” (default 4k) to the config in the ingress controller fixed the issue. I boiled this down to an HPACK framing issue early on but couldn’t prove it and didn’t have all of the tools to really inspect it so I was basically making an educated guess. Again I don’t understand how I have 3 scenarios where h2 is working but the 4th causes an issue and only from haproxy forward. Any insight into what haproxy is doing differently here would be invaluable.

You are more likely to get good answers if you file a bug report on github:

I was hesitant to call it a bug since the issue persisted across all current haproxy 2 versions. I’ll create one anyway.