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
Docs — replace Glossary with comprehensive per-test documentation
Replace the single Glossary page with 54 markdown files across 8 sections:
Line Endings, Request Line, Headers, Host Header, Content-Length,
Request Smuggling, and Malformed Input. Each test has its own page
with RFC references, requirement levels, and security context.
Also applies strict RFC compliance to probe scoring (MUST = 400 only,
SHOULD = 400 or close, MAY = either acceptable).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reference documentation for every test in Http11Probe, organized by topic. Each page explains the RFC requirement, what the test sends, what response is expected, and why it matters.
8
+
9
+
{{< cards >}}
10
+
{{< card link="rfc-basics" title="RFC Basics" subtitle="What RFCs are, how to read requirement levels (MUST/SHOULD/MAY), and which RFCs define HTTP/1.1." icon="book-open" >}}
11
+
{{< card link="line-endings" title="Line Endings" subtitle="CRLF requirements, bare LF handling, and bare CR rejection per RFC 9112 Section 2.2." icon="code" >}}
12
+
{{< card link="request-line" title="Request Line" subtitle="Request-line format, multiple spaces, missing target, fragments, HTTP version validation." icon="terminal" >}}
13
+
{{< card link="headers" title="Header Syntax" subtitle="Obs-fold, space before colon, empty names, invalid characters, missing colon." icon="document-text" >}}
14
+
{{< card link="host-header" title="Host Header" subtitle="Missing Host, duplicate Host — the only tests where RFC explicitly mandates 400." icon="server" >}}
15
+
{{< card link="content-length" title="Content-Length" subtitle="Non-numeric CL, plus sign, integer overflow, leading zeros, negative values." icon="calculator" >}}
16
+
{{< card link="smuggling" title="Request Smuggling" subtitle="CL+TE conflicts, TE obfuscation, pipeline injection, and why ambiguous framing is dangerous." icon="shield-exclamation" >}}
The `Content-Length` header indicates the size of the message body in bytes. Its grammar is strict: `Content-Length = 1*DIGIT`. Any deviation — non-numeric characters, plus signs, leading zeros, negative values, overflow — can cause parsers to disagree on body boundaries.
9
+
10
+
## Key Rules
11
+
12
+
**Grammar**: `1*DIGIT` means one or more ASCII digits (`0-9`). No signs, no spaces, no hex.
13
+
14
+
> “If a message is received without Transfer-Encoding and with an invalid Content-Length header field, then the message framing is invalid and the recipient **MUST** treat it as an unrecoverable error...” — RFC 9112 Section 6.3
A request with a non-numeric `Content-Length` value, e.g., `Content-Length: abc`.
17
+
18
+
## What the RFC says
19
+
20
+
Content-Length is defined as `1*DIGIT`. A value containing non-digit characters does not match this grammar.
21
+
22
+
> “If a message is received without Transfer-Encoding and with an invalid Content-Length header field, then the message framing is invalid and the recipient **MUST** treat it as an unrecoverable error...”
23
+
24
+
“Unrecoverable error” means the server must reject — either with a 400 response or by closing the connection. It cannot attempt to parse the body.
A request with a plus sign in the Content-Length value: `Content-Length: +42`.
17
+
18
+
## What the RFC says
19
+
20
+
The `+` character is not in the DIGIT set (`%x30-39`), so `+42` does not match `1*DIGIT`. This is an invalid Content-Length and MUST be treated as an unrecoverable error.
21
+
22
+
## Why it matters
23
+
24
+
Many programming languages’ integer parsers accept leading `+` signs (e.g., `parseInt("+42")` returns `42` in JavaScript). A server that blindly passes Content-Length through such a parser may accept this value while another server in the chain rejects it — creating a framing disagreement.
HTTP header fields follow a strict grammar: `field-name ":" OWS field-value OWS`. RFC 9112 Section 5 and RFC 9110 Section 5.6.2 define what constitutes a valid header. Violations can lead to parser disagreements and smuggling.
9
+
10
+
## Key Rules
11
+
12
+
**Space before colon** — the only header syntax violation with an explicit MUST-400:
13
+
14
+
> "A server **MUST** reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon." — RFC 9112 Section 5
15
+
16
+
**Obs-fold** (line folding with leading whitespace):
17
+
18
+
> "A server that receives an obs-fold in a request message that is not within a message/http container **MUST** either reject the message by sending a 400 (Bad Request)... or replace each received obs-fold with one or more SP octets prior to interpreting the field value." — RFC 9112 Section 5.1
19
+
20
+
**Field name** must be a `token` = `1*tchar`, meaning at least one valid token character. Empty names, non-ASCII bytes, and special characters are all violations.
21
+
22
+
## Tests
23
+
24
+
{{< cards >}}
25
+
{{< card link="sp-before-colon" title="SP-BEFORE-COLON" subtitle="Space between field name and colon. MUST reject with 400." >}}
26
+
{{< card link="obs-fold" title="OBS-FOLD" subtitle="Obsolete line folding. MUST reject with 400 or replace with SP." >}}
27
+
{{< card link="empty-header-name" title="EMPTY-HEADER-NAME" subtitle="Leading colon with no field name." >}}
28
+
{{< card link="invalid-header-name" title="INVALID-HEADER-NAME" subtitle="Non-token characters in field name." >}}
29
+
{{< card link="header-no-colon" title="HEADER-NO-COLON" subtitle="Header line with no colon separator." >}}
|**Requirement**| Implicit MUST (grammar violation) |
12
+
|**Expected**|`400` or close |
13
+
14
+
## What it sends
15
+
16
+
A header line starting with a colon — effectively an empty field name: `: value`.
17
+
18
+
## What the RFC says
19
+
20
+
Field names are defined as `token = 1*tchar`, requiring at least one valid token character. An empty string does not match `1*tchar`. While there is no explicit "MUST reject empty field names with 400" statement, a line starting with `:` fails to match the `field-line` grammar entirely.
21
+
22
+
## Sources
23
+
24
+
-[RFC 9112 Section 5 — Field Syntax](https://www.rfc-editor.org/rfc/rfc9112#section-5)
25
+
-[RFC 9110 Section 5.1 — Field Names](https://www.rfc-editor.org/rfc/rfc9110#section-5.1)
|**Requirement**| Implicit MUST (grammar violation) |
12
+
|**Expected**|`400` or close |
13
+
14
+
## What it sends
15
+
16
+
A header line with no colon: `InvalidHeaderNoColon`.
17
+
18
+
## What the RFC says
19
+
20
+
The field-line grammar is `field-name ":" OWS field-value OWS`. A line without a colon does not match this grammar. It could be misinterpreted as a continuation line, a new request, or garbage — any of which is dangerous.
21
+
22
+
## Sources
23
+
24
+
-[RFC 9112 Section 5 — Field Syntax](https://www.rfc-editor.org/rfc/rfc9112#section-5)
0 commit comments