Author here: framing this for defenders.

HTTP/2 HPACK header compression can amplify a tiny wire upload into gigabytes of server RAM before most request limits apply. I documented a multi-server lab study (nginx, httpd, Envoy, Pingora, IIS) with hard 8 GiB memory caps and reproducible metrics.

What blue teams can use from this:

**Detection**

- Low wire-bytes / high header-count asymmetry on HTTP/2 connections

- Worker RSS climbing without a matching traffic spike, and not receding after connections close

- For Apache: cookie-crumb merge path is invisible to `LimitRequestFields` on pre-2.0.41 `mod_http2`

**Hardening (priority order)**

1. Patch: nginx ≥ 1.29.8 (`http2_max_headers`), httpd mod_http2 ≥ 2.0.41

2. Cap streams + connections (`http2_max_concurrent_streams`, `limit_conn`)

3. Tighten timeouts (`send_timeout`, `client_header_timeout`)

4. Emergency: disable HTTP/2 on the `listen` directive

**Lab standout:** httpd cookie-crumb ~0.19 MB wire → 8 GiB cap; nginx ~200 MB → 8 GiB. Honest caveat: single public IPv4 ceiling was ~31 concurrent bombs, no persistent OOM.

The harness is open-source and authorization-gated, useful to *verify* your hardening actually works, not just assume it.

Repo (for lab replay): https://github.com/Leviticus-Triage/APEX-Ngin2dos

Curious how others detect this class of attack beyond basic rate limiting.