cc @neild

Any progress?

I have made a draft of what a PR would entail. Care to share your thoughts on this? @seankhliao @neild

Not sure if anyone is going to read this. Since #66298 has been merged is there reason to look at this as well? @neild

Sorry for the late reply.

What the HTTP receiver really cares about is the amount of bytes of headers, it's also what really matters. The number of headers tells us almost nothing because the amount of bytes is still ambiguous. If you're trying to limit the number of headers, I believe lowering the MaxHeaderBytes can also achieve the same effect. I'm concerned that adding a new configuration like MaxHeaderCount will bring more complexity to the net/http and confuse users, given that we already have an adequate solution: MaxHeaderBytes.

Tks for the response. As I've first described, the issue here is that a malicious request can have a lot of small header key-values and still fall within a reasonable MaxHeaderBytes limit. Since an incoming request header is always parsed into a map, the server will be making a lot of allocs for that request. The current code also puts a cap on the estimated map capacity, making the situation worse.

Amplifying the number of these malicious requests can put significant pressure on the gc, causing performance issues.

Reducing MaxHeaderBytes can help, but may not be feasible without affecting legitimate requests.

Even if we don't give the option to specify number of headers, a hardcoded a limit or limit configurable via env can work too.