update GenHTTP

Author: MDA2AV

docs/content/docs/caching/etag-304.md

@@ -34,11 +34,11 @@ Captures the `ETag` header from the response for use in step 2.
 ```http
 GET / HTTP/1.1\r\n
 Host: localhost:8080\r\n
-If-None-Match: "abc123"\r\n
+If-None-Match: {ETag from step 1}\r\n
 \r\n
 ```
 
-Sends the captured ETag value in an `If-None-Match` header. If the resource hasn't changed, the server should return `304 Not Modified`.
+Replays the `ETag` value captured from step 1 in an `If-None-Match` header. If the resource hasn't changed, the server should return `304 Not Modified`. If the server did not include an `ETag` header in step 1, the test reports Warn immediately.
 
 ## What the RFC says
 

docs/content/docs/caching/etag-in-304.md

@@ -34,11 +34,11 @@ Captures the `ETag` header from the response.
 ```http
 GET / HTTP/1.1\r\n
 Host: localhost:8080\r\n
-If-None-Match: "abc123"\r\n
+If-None-Match: {ETag from step 1}\r\n
 \r\n
 ```
 
-Sends the captured ETag. If the server returns `304`, this test checks whether the `ETag` header is present in that response.
+Replays the `ETag` value captured from step 1. If the server returns `304`, this test checks whether the `ETag` header is present in that response.
 
 ## What the RFC says
 

docs/content/docs/caching/etag-weak.md

@@ -34,7 +34,7 @@ Captures the `ETag` header from the response. If the ETag is strong (e.g., `"abc
 ```http
 GET / HTTP/1.1\r\n
 Host: localhost:8080\r\n
-If-None-Match: W/"abc123"\r\n
+If-None-Match: {ETag from step 1, weak}\r\n
 \r\n
 ```
 

docs/content/docs/caching/inm-precedence.md

@@ -34,12 +34,12 @@ Captures the `ETag` header from the response.
 ```http
 GET / HTTP/1.1\r\n
 Host: localhost:8080\r\n
-If-None-Match: "abc123"\r\n
+If-None-Match: {ETag from step 1}\r\n
 If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT\r\n
 \r\n
 ```
 
-The `If-None-Match` header matches the current ETag (should produce `304`), but the `If-Modified-Since` is set to epoch (should produce `200` since the resource was certainly modified after 1970). If the server returns `304`, it correctly evaluated `If-None-Match` first.
+Replays the `ETag` value captured from step 1 in `If-None-Match` (should produce `304`), combined with `If-Modified-Since` set to epoch (should produce `200` since the resource was certainly modified after 1970). If the server returns `304`, it correctly evaluated `If-None-Match` first.
 
 ## What the RFC says
 

docs/content/docs/caching/inm-unquoted.md

@@ -34,11 +34,11 @@ Captures the `ETag` header from the response for use in step 2.
 ```http
 GET / HTTP/1.1\r\n
 Host: localhost:8080\r\n
-If-None-Match: abc123\r\n
+If-None-Match: {ETag from step 1, unquoted}\r\n
 \r\n
 ```
 
-Sends the ETag value without the required surrounding double quotes. According to the RFC grammar, `entity-tag = [ weak ] opaque-tag` and `opaque-tag = DQUOTE *etagc DQUOTE` — the quotes are mandatory.
+Sends the ETag value captured from step 1, stripped of the required surrounding double quotes. According to the RFC grammar, `entity-tag = [ weak ] opaque-tag` and `opaque-tag = DQUOTE *etagc DQUOTE` — the quotes are mandatory.
 
 ## What the RFC says
 

docs/content/docs/caching/last-modified-304.md

@@ -34,11 +34,11 @@ Captures the `Last-Modified` header from the response for use in step 2.
 ```http
 GET / HTTP/1.1\r\n
 Host: localhost:8080\r\n
-If-Modified-Since: Sun, 01 Jan 2025 00:00:00 GMT\r\n
+If-Modified-Since: {Last-Modified from step 1}\r\n
 \r\n
 ```
 
-Sends the captured Last-Modified value in an `If-Modified-Since` header. If the resource hasn't changed since that date, the server should return `304 Not Modified`.
+Replays the `Last-Modified` value captured from step 1 in an `If-Modified-Since` header. If the resource hasn't changed since that date, the server should return `304 Not Modified`. If the server did not include a `Last-Modified` header in step 1, the test reports Warn immediately.
 
 ## What the RFC says
 

docs/content/docs/cookies/_index.md

@@ -1,45 +1,5 @@
 ---
-title: Cookies
-description: "Cookies — Http11Probe documentation"
-weight: 13
+title: Cookie Handling
 sidebar:
   open: false
 ---
-
-Cookie parsing is handled by framework-level parsers that run automatically on every request. Malformed `Cookie` headers can crash these parsers, cause memory issues, or produce mangled values. These tests check whether servers and frameworks survive adversarial cookie input.
-
-Cookies are defined by [RFC 6265](https://www.rfc-editor.org/rfc/rfc6265) (not RFC 9110/9112), so all tests are **unscored**.
-
-## Scoring
-
-All cookie tests are **unscored**:
-
-- **Pass** — Server handled the cookie input safely
-- **Warn** — Endpoint not available or non-ideal but non-dangerous behavior
-- **Fail** — Server crashed (500), preserved dangerous bytes, or lost data it should have parsed
-
-## Echo-Based Tests
-
-These tests target `/echo` and work on all servers. They check whether the server survives adversarial cookie headers without crashing.
-
-{{< cards >}}
-  {{< card link="echo" title="ECHO" subtitle="Basic Cookie header echoed back." >}}
-  {{< card link="oversized" title="OVERSIZED" subtitle="64KB Cookie header." >}}
-  {{< card link="empty" title="EMPTY" subtitle="Empty Cookie header value." >}}
-  {{< card link="nul" title="NUL" subtitle="NUL byte in cookie value." >}}
-  {{< card link="control-chars" title="CONTROL-CHARS" subtitle="Control characters in cookie value." >}}
-  {{< card link="many-pairs" title="MANY-PAIRS" subtitle="1000 cookie key=value pairs." >}}
-  {{< card link="malformed" title="MALFORMED" subtitle="Completely malformed cookie syntax." >}}
-  {{< card link="multi-header" title="MULTI-HEADER" subtitle="Two separate Cookie headers." >}}
-{{< /cards >}}
-
-## Parsed-Cookie Tests
-
-These tests target `/cookie` and check whether the framework's cookie parser correctly extracts key=value pairs. Servers without a `/cookie` endpoint return 404 (Warn).
-
-{{< cards >}}
-  {{< card link="parsed-basic" title="PARSED-BASIC" subtitle="Single foo=bar cookie parsed." >}}
-  {{< card link="parsed-multi" title="PARSED-MULTI" subtitle="Three cookies parsed from one header." >}}
-  {{< card link="parsed-empty-val" title="PARSED-EMPTY-VAL" subtitle="Cookie with empty value." >}}
-  {{< card link="parsed-special" title="PARSED-SPECIAL" subtitle="Spaces and = in cookie values." >}}
-{{< /cards >}}

docs/content/docs/cookies/control-chars.md

@@ -1,6 +1,6 @@
 ---
 title: "CONTROL-CHARS"
-description: "COOK-CONTROL-CHARS test documentation"
+description: "COOK-CONTROL-CHARS cookie test documentation"
 weight: 5
 ---
 
@@ -9,37 +9,29 @@ weight: 5
 | **Test ID** | `COOK-CONTROL-CHARS` |
 | **Category** | Cookies |
 | **Scored** | No |
-| **Expected** | `400` (rejected) or `2xx` without control chars |
+| **RFC Level** | N/A |
+| **Expected** | `400 (rejected) or 2xx without control chars` |
 
 ## What it sends
 
+Control characters (0x01-0x03) in cookie value — dangerous if preserved.
+
 ```http
 GET /echo HTTP/1.1\r\n
 Host: localhost:8080\r\n
 Cookie: foo=\x01\x02\x03\r\n
 \r\n
 ```
 
-A `Cookie` header containing control characters SOH (`0x01`), STX (`0x02`), and ETX (`0x03`) as the cookie value.
-
-## What the RFC says
-
-> "cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E" — RFC 6265 §4.1.1
-
-Control characters (`0x00-0x1F`) are explicitly excluded from the `cookie-octet` production. They are not valid in cookie values.
-
 ## Why it matters
 
-Control characters in cookie values can cause:
-- **Log injection** — if the bytes reach log files, they may corrupt formatting or inject terminal escape sequences
-- **Parser confusion** — some parsers may interpret control characters as delimiters
-- **Security filter bypass** — WAFs may not inspect or sanitize non-printable bytes
+Control characters in cookie values violate RFC 6265's cookie-octet grammar and can enable response splitting or log injection if passed through to output.
 
 ## Verdicts
 
-- **Pass** — `400` (rejected) or `2xx` with control characters stripped/cookie dropped
-- **Fail** — `2xx` with control characters preserved in the response body
+- **Pass** — 400 rejected, or 2xx with control chars stripped
+- **Fail** — 2xx with control chars preserved (dangerous), or 500
 
 ## Sources
 
-- [RFC 6265 §4.1.1](https://www.rfc-editor.org/rfc/rfc6265#section-4.1.1) — cookie-octet definition
+- [RFC 6265 §5.4](https://www.rfc-editor.org/rfc/rfc6265#section-5.4) — Cookie header

docs/content/docs/cookies/echo.md

@@ -1,6 +1,6 @@
 ---
 title: "ECHO"
-description: "COOK-ECHO test documentation"
+description: "COOK-ECHO cookie test documentation"
 weight: 1
 ---
 
@@ -9,34 +9,29 @@ weight: 1
 | **Test ID** | `COOK-ECHO` |
 | **Category** | Cookies |
 | **Scored** | No |
-| **Expected** | `2xx` with `Cookie:` in echo body |
+| **RFC Level** | N/A |
+| **Expected** | `2xx with Cookie in body` |
 
 ## What it sends
 
+Basic Cookie header echoed back by /echo endpoint.
+
 ```http
 GET /echo HTTP/1.1\r\n
 Host: localhost:8080\r\n
 Cookie: foo=bar\r\n
 \r\n
 ```
 
-A standard request with a simple, valid `Cookie` header targeting the `/echo` endpoint.
-
-## What the RFC says
-
-> "When the user agent generates an HTTP request, the user agent MUST NOT attach more than one header field named Cookie." — RFC 6265 §5.4
-
-This test sends a single, well-formed `Cookie` header. It serves as a baseline to confirm the echo endpoint reflects cookie headers.
-
 ## Why it matters
 
-This is the baseline cookie test. If the server cannot echo back a simple `Cookie: foo=bar` header, all other cookie tests are meaningless.
+Baseline test — verifies the server's echo endpoint reflects Cookie headers, which is required for all other cookie tests to work.
 
 ## Verdicts
 
-- **Pass** — 2xx response with `Cookie:` visible in the echo body
-- **Fail** — No response, or 2xx without the cookie header in the body
+- **Pass** — 2xx and body contains `Cookie:` header
+- **Fail** — No response or missing header
 
 ## Sources
 
-- [RFC 6265 §5.4](https://www.rfc-editor.org/rfc/rfc6265#section-5.4) — sending cookies
+- [RFC 6265 §5.4](https://www.rfc-editor.org/rfc/rfc6265#section-5.4) — Cookie header

docs/content/docs/cookies/empty.md

@@ -1,6 +1,6 @@
 ---
 title: "EMPTY"
-description: "COOK-EMPTY test documentation"
+description: "COOK-EMPTY cookie test documentation"
 weight: 3
 ---
 
@@ -9,34 +9,29 @@ weight: 3
 | **Test ID** | `COOK-EMPTY` |
 | **Category** | Cookies |
 | **Scored** | No |
-| **Expected** | `2xx` or `400` |
+| **RFC Level** | N/A |
+| **Expected** | `2xx or 400` |
 
 ## What it sends
 
+Empty Cookie header value — tests parser resilience.
+
 ```http
 GET /echo HTTP/1.1\r\n
 Host: localhost:8080\r\n
 Cookie: \r\n
 \r\n
 ```
 
-A `Cookie` header with an empty value (nothing after the colon and space).
-
-## What the RFC says
-
-> "cookie-header = 'Cookie:' OWS cookie-string OWS" — RFC 6265 §4.2
-
-An empty cookie-string does not match `cookie-pair *( ";" SP cookie-pair )` since `cookie-pair` requires at least a name. However, servers should handle this gracefully.
-
 ## Why it matters
 
-Empty `Cookie` headers can trigger null-pointer dereferences or empty-string edge cases in cookie parsers. The test verifies the server doesn't crash.
+Empty Cookie headers can cause null-reference exceptions or crashes in parsers that assume at least one key=value pair.
 
 ## Verdicts
 
-- **Pass** — `2xx` (accepted) or `400` (rejected gracefully)
-- **Fail** — `500` or connection crash
+- **Pass** — 2xx or 400
+- **Fail** — 500 (crash)
 
 ## Sources
 
-- [RFC 6265 §4.2](https://www.rfc-editor.org/rfc/rfc6265#section-4.2) — cookie header syntax
+- [RFC 6265 §5.4](https://www.rfc-editor.org/rfc/rfc6265#section-5.4) — Cookie header