It takes a little effort to fully understand the configuration file format (hint: you've got to read the documentation, not just look at examples to fully grok it), but it's so worth it, IMO.
It's also a nice treat to have the founder and technical leader (Willy Tarreau) of the HAProxy company being so active in the community, so many years later (the initital release was in 2001). I regularly see him answering e.g. newbie questions.
(HAProxy docs: https://docs.haproxy.org/ - pick 2.8/LTS)
> So at first glance we indeed addressed this case in 2018 (1.9-dev) with this commit:
> f210191dc ("BUG/MEDIUM: h2: don't accept new streams if conn_streams are still in excess")
> It was incomplete by then an later refined, but the idea is there. But I'll try to stress that area again to see.
[0] https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...
After rigorous testing, we have been able to confirm that our implementation of the HTTP/2 protocol can handle the Rapid Reset Attack without increasing the resource usage or compromising the parallelism of the protocol.
A trivial implementation might walk through the packet front-to-back, firing off requests and cancellations immediately as it encounters them. That would indeed still result in a lot of load on the servers behind the proxy.
However, a reasonable alternative would be to only collect a set of actions to execute while walking through the packet, firing them off all at once when you finish. For example, a "launch request" could create a new entry in the backend requests list with a state of "NEW". The "cancel request" part immediately afterwards could then look in the backend request list and set the state of the corresponding request to "CANCEL".
Now when the backend request list is being processed next, it'll only see a request marked "CANCEL" without a corresponding socket to a backend, shrug, and just delete the entry because there is nothing to do.
[0]: https://blog.cloudflare.com/technical-breakdown-http2-rapid-...
That's why HAProxy did testing to see if they were vulnerable.
https://cloud.google.com/blog/products/identity-security/how...