Should servers be emitting many HTTP/2 control frames?

**Jetty Version**
10.0.26+

**Java Version**
Java 21

**Question**
We are running into an issue where upgrading to Jetty 10.0.26 results in some 500s because the MadeYouReset CVE-2025-5115 mitigation ([pr](https://github.com/jetty/jetty.project/pull/13449/files#diff-35ba04398003e4533a9ebd151efafb99992a35d4ab66ed22e22595a6d117d390R840)) now includes server side control frames in the WindowRateControl limiter and is dropping HTTP/2 connections.

We manually increased the RateControl limit from 128 -> 1000 but we're still seeing connections dropped for some of our high QPS services. Whereas before 10.0.26, events per second was less than 5~50, it now jumps to 1000+.

My question is, is it expected for the server to be sending this many HTTP/2 control frames per second? It seems like this behavior was always present but is now becoming a problem with the rate limiter. In what scenarios would the server be sending the RST_STREAM control frame?

Start with the MadeYouReset mitigation linked in the issue and the WindowRateControl limiter introduced for Jetty 10.0.26. Compare how server-side HTTP/2 control frames, especially RST_STREAM, are counted before and after that version, then identify the scenarios producing the reported rate. Done means explaining whether the volume is expected and what change would prevent unintended connection drops.

Written by the indexing model from the issue text.