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
This page classifies every test by its RFC 2119 requirement level. You must:
223
+
224
+
1.**Add a row** to the correct table based on the test's requirement level:
225
+
-`MUST` / `MUST NOT` → "MUST-Level Requirements" table (use the "Reject with 400" sub-table if the RFC explicitly mandates 400, otherwise the "Reject (400 or Connection Close Acceptable)" sub-table)
Copy file name to clipboardExpand all lines: docs/content/_index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,7 @@ layout: hextra-home
24
24
25
25
{{< cards >}}
26
26
{{< card link="probe-results" title="Leaderboard" subtitle="See which frameworks pass the most tests, ranked from best to worst compliance." icon="chart-bar" >}}
Copy file name to clipboardExpand all lines: docs/content/docs/_index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ Reference documentation for every test in Http11Probe, organized by topic. Each
10
10
11
11
{{< cards >}}
12
12
{{< card link="http-overview" title="Understanding HTTP" subtitle="What HTTP is, how HTTP/1.1 works at the wire level, its history from 0.9 to 3, and alternatives." icon="globe-alt" >}}
{{< card link="rfc-requirement-dashboard" title="RFC Requirement Dashboard" subtitle="Every test classified by RFC 2119 requirement level (MUST/SHOULD/MAY)." icon="document-search" >}}
14
14
{{< 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" >}}
15
15
{{< card link="baseline" title="Baseline" subtitle="Sanity request used to confirm the target is reachable before running negative tests." icon="check-circle" >}}
16
16
{{< 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" >}}
An OPTIONS request to the root path. Some servers respond with `204 No Content`, which triggers the validation.
18
+
19
+
```http
20
+
OPTIONS / HTTP/1.1\r\n
21
+
Host: localhost:8080\r\n
22
+
\r\n
23
+
```
24
+
25
+
## What the RFC says
26
+
27
+
> "A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content)." -- RFC 9110 Section 8.6
28
+
29
+
## Why it matters
30
+
31
+
A `204 No Content` response explicitly signals that there is no body. Including `Content-Length` contradicts this, and some clients or proxies may attempt to read body bytes based on the Content-Length value. On persistent connections, this causes desync — the client reads the next response's bytes as body data for the 204, corrupting the entire connection. If the server does not return 204 for this request, the test reports a warning since the prohibition cannot be verified.
A standard GET request. The test validates that the server includes a `Content-Type` header when the response contains a body.
18
+
19
+
```http
20
+
GET / HTTP/1.1\r\n
21
+
Host: localhost:8080\r\n
22
+
\r\n
23
+
```
24
+
25
+
## What the RFC says
26
+
27
+
> "A sender that generates a message containing content SHOULD generate a Content-Type header field in the message unless the intended media type of the enclosed representation is unknown to the sender." -- RFC 9110 Section 8.3
28
+
29
+
And:
30
+
31
+
> "If a Content-Type header field is not present, the recipient MAY either assume a media type of 'application/octet-stream' or examine the data to determine its type." -- RFC 9110 Section 8.3
32
+
33
+
## Why it matters
34
+
35
+
Without Content-Type, clients must guess the media type through content sniffing, which is a well-known security risk. Browsers performing MIME sniffing may interpret a response as HTML when it was intended as plain text, enabling XSS attacks. Including Content-Type is a baseline security practice.
A standard GET request. The test validates that the server includes a `Date` header in its response.
18
+
19
+
```http
20
+
GET / HTTP/1.1\r\n
21
+
Host: localhost:8080\r\n
22
+
\r\n
23
+
```
24
+
25
+
## What the RFC says
26
+
27
+
> "An origin server with a clock MUST generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses, and MAY generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses." -- RFC 9110 Section 6.6.1
28
+
29
+
## Why it matters
30
+
31
+
The Date header is essential for HTTP caching. Caches use it to calculate age, determine freshness, and resolve clock skew between origin servers and intermediaries. Without it, caches cannot properly compute expiration times, leading to either stale content being served or unnecessary revalidation.
An HTTP/1.0 POST with `Expect: 100-continue` and a body, designed to test whether the server incorrectly sends a `100 Continue` interim response to an HTTP/1.0 client.
18
+
19
+
```http
20
+
POST / HTTP/1.0\r\n
21
+
Host: localhost:8080\r\n
22
+
Expect: 100-continue\r\n
23
+
Content-Length: 5\r\n
24
+
\r\n
25
+
hello
26
+
```
27
+
28
+
## What the RFC says
29
+
30
+
> "Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client." -- RFC 9110 Section 15.2
31
+
32
+
## Why it matters
33
+
34
+
HTTP/1.0 clients do not understand interim responses. If a server sends `100 Continue` to an HTTP/1.0 client, the client may interpret the `100` status line as a malformed final response, discard it as garbage, or enter an undefined state. This is especially dangerous in proxy chains where an HTTP/1.0 hop cannot forward 1xx responses correctly.
0 commit comments