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
Copy file name to clipboardExpand all lines: docs/content/docs/_index.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,6 +10,7 @@ Reference documentation for every test in Http11Probe, organized by topic. Each
10
10
11
11
{{< cards >}}
12
12
{{< 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" >}}
13
+
{{< card link="baseline" title="Baseline" subtitle="Sanity request used to confirm the target is reachable before running negative tests." icon="check-circle" >}}
13
14
{{< 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" >}}
14
15
{{< card link="request-line" title="Request Line" subtitle="Request-line format, multiple spaces, missing target, fragments, HTTP version validation." icon="terminal" >}}
15
16
{{< card link="headers" title="Header Syntax" subtitle="Obs-fold, space before colon, empty names, invalid characters, missing colon." icon="document-text" >}}
4. However, the RFC also says servers "ought to limit the total length of chunk extensions" and may generate a 4xx response if limits are exceeded. This introduces a legitimate reason for a `400` response.
76
76
5. The extension in this test (`ext=value`) is short (9 bytes), so a length-limit rejection would be unreasonable. But the RFC permits it in principle.
77
77
78
-
### Scored / Unscored justification
78
+
### Scoring justification
79
79
80
-
**Unscored.** The MUST keyword applies to *ignoring unrecognized* extensions, which implies the server should parse and skip them. However, the RFC also explicitly permits servers to reject requests with excessive chunk extensions via a 4xx response. Because the boundary between "acceptable" and "excessive" is left to the server's discretion, there is room for a compliant server to reject even short extensions. The test uses SHOULD accept (`2xx` = Pass, `400` = Warn) to acknowledge that `2xx` is the preferred behavior while `400` is not a clear violation.
80
+
This test is **scored** because the payload uses a short, syntactically valid chunk extension. For this input, RFC 9112 §7.1.1 says recipients MUST ignore unrecognized extensions and continue processing.
81
+
`2xx` is Pass.
82
+
`400` is Warn (strict behavior seen in the wild, but not the preferred RFC behavior for this specific payload).
@@ -35,8 +35,8 @@ Although the RFC says servers MUST accept absolute-form, in practice most non-pr
35
35
36
36
## Why it matters
37
37
38
-
**Pass:** Server rejects with `400` (common origin-server behavior).
39
-
**Warn:** Server accepts with `2xx` (RFC-compliant, accepts absolute-form).
38
+
**Pass:** Server accepts with `2xx` (RFC-compliant).
39
+
**Warn:** Server rejects with `400` (common in practice, but non-compliant with MUST accept).
40
40
41
41
## Deep Analysis
42
42
@@ -74,7 +74,7 @@ The `absolute-form` production requires a complete `absolute-URI` as defined in
74
74
75
75
### Scoring Justification
76
76
77
-
**Unscored.**Although the RFC uses "MUST accept," this requirement primarily targets proxy servers. An origin server that rejects absolute-form (returning `400`) is technically non-compliant but is not creating a security vulnerability -- it is simply refusing a request format it was not designed to handle. Both `400` and `2xx`are treated as acceptable outcomes.
77
+
**Unscored.** RFC 9112 uses a server-side MUST to accept absolute-form. In practice, many origin stacks still reject it. To preserve interoperability visibility without hard-failing broad classes of servers, this test is unscored: `2xx`is Pass and `400` is Warn.
@@ -76,7 +76,7 @@ The token `identity` is syntactically valid per the ABNF (it consists entirely o
76
76
77
77
This test is **scored** (MUST reject). Although the SHOULD in RFC 9112 section 6.1 for unrecognized transfer codings is not a MUST, the combined presence of Transfer-Encoding and Content-Length triggers the MUST-level requirement in section 6.1 to close the connection. The server cannot safely process `Transfer-Encoding: identity` because it is not a recognized coding, and the dual-header scenario mandates connection closure at minimum.
78
78
79
-
-**Pass (400 or close):** The server correctly rejects the unknown transfer coding or closes the connection per the dual-header rule.
79
+
-**Pass (400/501 or close):** The server rejects the unknown transfer coding or closes the connection per the dual-header rule.
80
80
-**Fail (2xx):** The server accepted a request with an unrecognized transfer coding and conflicting Content-Length, violating the connection-closure requirement.
|**Requirement**| MUST reject or unfold obs-fold |
13
+
|**Expected**|`400`, or `2xx` with connection close|
14
14
15
15
## What it sends
16
16
@@ -37,7 +37,7 @@ When obs-fold is used on the Transfer-Encoding header with Content-Length also p
37
37
38
38
## Why it matters
39
39
40
-
This is a high-confidence smuggling vector. The obs-fold mechanism was deprecated precisely because of parser disagreements. When applied to Transfer-Encoding — the header that determines message framing — it creates a situation where one parser uses chunked encoding and another uses Content-Length, enabling request smuggling. The RFC requires rejection (MUST), and no `AllowConnectionClose` alternative is acceptable because the server must actively reject the malformed header rather than simply closing the connection.
40
+
This is a high-confidence smuggling vector. The obs-fold mechanism was deprecated precisely because of parser disagreements. When applied to Transfer-Encoding, one parser can unfold to `chunked` while another ignores it and falls back to Content-Length.
41
41
42
42
## Deep Analysis
43
43
@@ -71,10 +71,11 @@ The `obs-fold` rule (obsolete line folding) allows a field value to be continued
71
71
72
72
### Scored / Unscored Justification
73
73
74
-
This test is **scored** (MUST reject with `400`). RFC 9112 section 5.2 provides a MUST-level requirement for servers receiving obs-fold. While the RFC allows two options (reject or unfold), this test expects strict `400` rejection because the obs-fold is applied to the Transfer-Encoding header -- the header that determines message framing. Allowing an unfolded interpretation when Content-Length is also present would require the server to then handle the CL/TE dual-header scenario, adding further complexity and risk. No `AllowConnectionClose` alternative is acceptable because the server must actively reject the malformed header.
74
+
This test is **scored**. RFC 9112 §5.2 gives two compliant server behaviors: reject with `400`, or replace obs-fold with SP and continue. If unfolded, the message still carries both TE and CL, so RFC 9112 §6.1 requires closing the connection after responding.
75
75
76
-
-**Pass (400):** The server correctly rejects the obs-fold per the MUST requirement.
77
-
-**Fail (2xx or close):** The server either silently accepted the folded header or merely closed the connection without the required `400` response.
76
+
-**Pass:**`400`.
77
+
-**Warn:**`2xx` with connection close (accepted unfold path).
0 commit comments