What this is about:sww waf decides for each request whether rproxy passes it to the app. Since #320, its cheap sanity checks (more than 50 cookies or 100 header fields, answered 431) run first, before any lookup or the Core Rule Set, as you asked on #308.
The open point: one very long line is not caught early. rproxy accepts a request line and headers up to 32 KiB in all, so a single 30 KB query string or cookie reaches the Core Rule Set, which then spends about a third to half a second on that one request. nginx refuses lines over 8 KiB by default, so ordinary clients and apps already stay under it. Measurements: #308 (comment).
Example: GET /search?q= followed by 30,000 characters. Today it goes through every check and the Core Rule Set. With the limit, waf refuses it at once with 414.
Options:
Add the limits, with no setting (recommended): waf refuses a request line over 8 KiB with 414, and a request with any one header line over 8 KiB with 431, as its first checks beside the header limits. The figure is fixed, as the cookie and header-count limits are.
Leave it: such requests keep going through every check; nothing changes.
Question: which one?
Model: opus-5-5
**What this is about:** `sww waf` decides for each request whether `rproxy` passes it to the app. Since https://git.eeqj.de/sneak/smallwebwaf/pulls/320, its cheap sanity checks (more than 50 cookies or 100 header fields, answered `431`) run first, before any lookup or the Core Rule Set, as you asked on https://git.eeqj.de/sneak/smallwebwaf/issues/308.
**The open point:** one very long line is not caught early. `rproxy` accepts a request line and headers up to 32 KiB in all, so a single 30 KB query string or cookie reaches the Core Rule Set, which then spends about a third to half a second on that one request. nginx refuses lines over 8 KiB by default, so ordinary clients and apps already stay under it. Measurements: https://git.eeqj.de/sneak/smallwebwaf/issues/308#issuecomment-176221.
Example: `GET /search?q=` followed by 30,000 characters. Today it goes through every check and the Core Rule Set. With the limit, `waf` refuses it at once with `414`.
**Options:**
- **Add the limits, with no setting** (recommended): `waf` refuses a request line over 8 KiB with `414`, and a request with any one header line over 8 KiB with `431`, as its first checks beside the header limits. The figure is fixed, as the cookie and header-count limits are.
- **Leave it:** such requests keep going through every check; nothing changes.
**Question:** which one?
Model: opus-5-5
sneak
was assigned by clawbot2026-11-11 07:14:22 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What this is about:
sww wafdecides for each request whetherrproxypasses it to the app. Since #320, its cheap sanity checks (more than 50 cookies or 100 header fields, answered431) run first, before any lookup or the Core Rule Set, as you asked on #308.The open point: one very long line is not caught early.
rproxyaccepts a request line and headers up to 32 KiB in all, so a single 30 KB query string or cookie reaches the Core Rule Set, which then spends about a third to half a second on that one request. nginx refuses lines over 8 KiB by default, so ordinary clients and apps already stay under it. Measurements: #308 (comment).Example:
GET /search?q=followed by 30,000 characters. Today it goes through every check and the Core Rule Set. With the limit,wafrefuses it at once with414.Options:
wafrefuses a request line over 8 KiB with414, and a request with any one header line over 8 KiB with431, as its first checks beside the header limits. The figure is fixed, as the cookie and header-count limits are.Question: which one?
Model: opus-5-5