You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add 34 new HTTP/1.1 compliance, smuggling, and robustness tests (46 → 80)
New tests cover RFC 9110/9112 requirements for: comma-separated CL,
chunked encoding edge cases (not-final, bare semicolon, hex prefix,
underscores, leading spaces, missing CRLF, overflow, long extensions),
TE in HTTP/1.0, bare CR in headers, Host validation (duplicate same,
userinfo, path), asterisk-form, absolute-form, CONNECT empty port,
method case sensitivity, leading CRLF, unknown TE, NUL in headers,
and HTTP/2 preface detection. Includes probe STRICT dict entries and
glossary documentation for all new tests.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
A request with whitespace (SP) before the first header line, between the request-line and the headers.
18
+
19
+
## What the RFC says
20
+
21
+
> "A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing of it." — RFC 9112 Section 2.2
22
+
23
+
## Why it matters
24
+
25
+
Whitespace before headers can confuse parsers about where headers begin, potentially enabling smuggling.
> "A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that... contains more than one Host header field line..." — RFC 9112 Section 3.2
22
+
23
+
## Why it matters
24
+
25
+
The RFC mandates 400 for *any* duplicate Host headers, regardless of whether the values match. Some servers incorrectly allow identical duplicates.
> "A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that... contains... a Host header field with an invalid field value." — RFC 9112 Section 3.2. The Host header grammar is `uri-host [ ":" port ]` with no path component allowed.
22
+
23
+
## Why it matters
24
+
25
+
A path in the Host header is a clear sign of manipulation. If a reverse proxy uses the Host to route, a path component could alter routing.
> "A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that... contains... a Host header field with an invalid field value." — RFC 9112 Section 3.2. The Host header grammar is `uri-host [ ":" port ]` — no userinfo is permitted.
22
+
23
+
## Why it matters
24
+
25
+
The userinfo component (`user@`) is not part of the Host grammar. A server that accepts it may be tricked into routing requests incorrectly.
Two leading CRLF sequences before the request-line.
18
+
19
+
## What the RFC says
20
+
21
+
> "In the interest of robustness, a server that is expecting to receive and parse a request-line SHOULD ignore at least one empty line (CRLF) received prior to the request-line." — RFC 9112 Section 2.2
22
+
23
+
## Why it matters
24
+
25
+
This is an unscored test. The RFC encourages servers to tolerate leading CRLFs. Either `400` (strict) or `2xx` (tolerant) is acceptable.
0 commit comments