Reject obs-fold and whitespace-before-colon in request headers (RFC 7230 3.2.4)

[stephenberry]

Summary

Hardens try_parse_request to reject two malformed header-field forms that are HTTP request-smuggling vectors, per RFC 7230 §3.2.4:

1. Obsolete line folding (obs-fold) — a header line beginning with SP/HTAB.
2. Whitespace between the field-name and the colon — e.g. Transfer-Encoding : chunked or a tab before the colon.

Both are now answered with 400 Bad Request + connection close.

Why

The header parser lowercases names and looks them up exactly (headers.find("transfer-encoding"), find("content-length")). It previously stored names without trimming or rejecting malformed whitespace, so an obfuscated header was stored under a key the lookup misses:

• Transfer-Encoding : chunked → key "transfer-encoding " (trailing space)
• Transfer-Encoding\t: chunked → key "transfer-encoding\t"
• a folded continuation → key "\ttransfer-encoding"

In every case the server sees no Transfer-Encoding/Content-Length, frames the body as empty, and leaves the encoded payload in the keep-alive buffer, where it is reparsed as a second, smuggled request. A front-end proxy that is tolerant of folding/whitespace frames the body as chunked and forwards the lot as one request — a classic TE/CL desync.

This complements #2654, which rejects a clean Transfer-Encoding header. Each closes a different half of the same class:

Variant	#2654	This PR
Transfer-Encoding: chunked	501 + close	(unchanged)
Transfer-Encoding : chunked (space)	bypassed	400 + close
Transfer-Encoding\t: chunked (tab)	bypassed	400 + close
obs-fold continuation carrying TE	bypassed	400 + close

Rejecting (rather than trimming) is deliberate: silently honoring Content-Length : 5 where a peer might frame it differently would just reintroduce the ambiguity. Closing the connection discards the leftover bytes (same safe path the existing 400 responses use). obs-fold is deprecated and not emitted by conforming clients, so false-positive risk is negligible.

Testing

New http_header_strictness_test (binds to an ephemeral port and reads it back via server.port()) covers all three smuggling vectors — asserting 400 and that the smuggled GET /smuggled never reaches a handler — plus a positive control proving well-formed requests with spaces/colons in header values still route and return 200.

Verified locally (Release + sanitizers):

• http_header_strictness_test: 4 tests / 8 asserts pass.
• No regressions: http_server_post_test, http_server_api_tests, http_chunked_test (59/233), http_router_test (21/81), cors_test (5/13) all pass.