Wondering if there are any security implications / risks involved with a server returning relatively large (100+) HTTP header lengths?
Several firewalls (or IDS, IPS, UTM, NGFW - whatever you call them) have limits on the length of content they analyze for malware (usually around 10MB, but sometimes even lower). Some include the length of the HTTP header into this computation. In this case the analysis of the HTTP body (containing the malware) can be bypassed when the HTTP header is already larger than the inspection limit.
The HTTP RFC does not fix the header length but is at least stating:
Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
That was for the first line. For headers you have (bold added):
HTTP does not place a predefined limit on the length of each header field or on the length of the header section as a whole, as described in Section 2.5. Various ad hoc limitations on individual header field length are found in practice, often depending on the specific field semantics.
A server that receives a request header field, or set of fields, larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (Section 9.5).
A client MAY discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
And in practice the 8000 bytes limit is usually found on headers also.
When handling long headers, having just one header ignored is dangerous (
Content-Length:<10,000spaces>42). Removing one header can tranform completly the meaning of the HTTP stream (not only the current message, but also other pipelined messages).
But header removal is not the only risk, they was an of an old truncation at 5000 bytes by IIS in the past. It could also be used to hide an active HTTP payload (like a
Transfer-Encoding: chunked<5000 spaces>, gzip header or
Content-Length: <4883 spaces>42 where any actor removing the end of the header may badly interpret the real message length (and maybe find a new pipelined message that other HTTP actors did not saw).