proposal: net/http: add option to limit header count in Server

[imacks]

Proposal

Right now net/http has Server.MaxHeaderBytes to limit request header size. Proposing an additional Server.MaxHeaderCount to limit total number of headers.

Rationale

Granted that Server already has quite a number of tunable fields, none address the issue of DOS attacks that send a boatload of headers. Even when limiting total header size to 64k, an attacker can still send ~13k headers in a single request. This puts visible pressure on the GC as the number of malicious requests scale up.

Implementing this is trivial with existing code.

Any hint of a workaround would be appreciated too.

[seankhliao]

cc @neild

[imacks]

Any progress?

[imacks]

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

[imacks]

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

[panjf2000]

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.

[imacks]

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.