Docs: rproxy runs behind any TLS-terminating reverse proxy (closes #388)

README, SPEC and docs no longer present traefik as the required front
proxy. The README gains "The reverse proxy in front", listing what that
proxy must do: forward plain HTTP to port 8080, keep Host, set
X-Forwarded-For and X-Forwarded-Proto, and connect from an address in
SWW_RPROXY_TRUSTED_PROXIES. traefik, Caddy and nginx appear as examples,
with the nginx headers spelled out since it sets none by default.

Model: opus-5-5

README.md

@@ -10,10 +10,11 @@ A web application firewall reads each request on its way to a web app and
 refuses the ones that look like abuse. `smallwebwaf` is one program, `sww`,
 shipped in one image, with two commands that do this together:
 
-- `sww rproxy` is a small reverse proxy in front of one app. traefik routes to
+- `sww rproxy` is a small reverse proxy in front of one app. It sits behind the
-  it. It asks `waf` about each request, passes the allowed ones to the app, and
+  reverse proxy that terminates TLS, such as traefik, nginx or Caddy. It asks
-  passes the app's answers back. It keeps nothing between requests and writes
+  `waf` about each request, passes the allowed ones to the app, and passes the
-  nothing to disk.
+  app's answers back. It keeps nothing between requests and writes nothing to
+  disk.
 - `sww waf` decides. It runs the checks and keeps the bans, the counters and
   each client's history. One `waf` serves many sites: a client banned through
   one site is refused on all of them, and its requests on all of them count
@@ -57,8 +58,8 @@ For the operator, it:
 
 Not built, and not planned:
 
-- TLS and routing by host name. Both stay with traefik, the reverse proxy in
+- TLS and routing by host name. Both stay with the reverse proxy in front of
-  front of `rproxy`.
+  `rproxy`.
 - Browser challenges such as captchas.
 - A web console, or a configuration file.
 - Defence against floods large enough to fill the host's network link.
@@ -90,20 +91,48 @@ accepts connections, whether or not `waf` answers; in `waf`'s container, once
 The usual setup is three containers on one private network:
 
 - the app;
-- `rproxy`, in front of the app, which traefik routes to:
+- `rproxy`, in front of the app, which the reverse proxy that terminates TLS
-  `SWW_RPROXY_WAF_BACKEND` names `waf` and `SWW_RPROXY_UPSTREAM_URL` names the
+  forwards to: `SWW_RPROXY_WAF_BACKEND` names `waf` and
-  app;
+  `SWW_RPROXY_UPSTREAM_URL` names the app;
 - `waf`, with `SWW_COMMAND=waf` and a volume at `/var/lib/sww` for its state
   files.
 
-Point traefik's labels at port 8080 of `rproxy`
+Publish no port of the app or of `waf`. Anything on that network can reach the
-(`traefik.http.services.<name>.loadbalancer.server.port=8080`). Publish no port
+app around `rproxy`, and can ask `waf` questions, so the network holds only what
-of the app or of `waf`. Anything on that network can reach the app around
+you trust. Each further app adds its own container and its own `rproxy`, whose
-`rproxy`, and can ask `waf` questions, so the network holds only what you trust.
-Each further app adds its own container and its own `rproxy`, whose
 `SWW_RPROXY_WAF_BACKEND` names the same `waf`. The "Smallest setup" example
 below shows this shape.
 
+### The reverse proxy in front
+
+`rproxy` serves plain HTTP. It runs behind any reverse proxy that terminates
+TLS, such as traefik, nginx or Caddy. That proxy must:
+
+- forward each request to port 8080 of `rproxy` over plain HTTP;
+- keep the visitor's `Host` header;
+- add the visitor's address to `X-Forwarded-For`;
+- set `X-Forwarded-Proto` to the scheme the visitor used;
+- connect to `rproxy` from an address in `SWW_RPROXY_TRUSTED_PROXIES`, by
+  default `10.0.0.0/8`, `172.16.0.0/12` or `192.168.0.0/16`.
+
+From any other address, `rproxy` ignores the forwarded headers and takes the
+proxy for the visitor. Every visitor then shares one address, and one ban.
+
+traefik and Caddy keep the `Host` header and set both forwarded headers by
+default. traefik's Docker label
+`traefik.http.services.<name>.loadbalancer.server.port=8080` names the port, and
+Caddy's `reverse_proxy rproxy:8080` needs nothing more. nginx sets none of the
+headers by default, so its site names them:
+
+```nginx
+location / {
+    proxy_pass http://rproxy:8080;
+    proxy_set_header Host $host;
+    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+    proxy_set_header X-Forwarded-Proto $scheme;
+}
+```
+
 ### `rproxy` in the app's container
 
 An app's image can instead be built on the `smallwebwaf` image, so that `rproxy`
@@ -154,13 +183,13 @@ entrypoint starts `rproxy` and the app side by side, each as its own user. Run
 the app's image with `SWW_RPROXY_WAF_BACKEND` set. `deploy/example-app` is such
 an app, and the "`rproxy` beside the app" example below runs one.
 
-The app sees the headers traefik sent, with traefik's address added to
+The app sees the headers the reverse proxy in front sent, with that proxy's
-`X-Forwarded-For`, from a TCP peer that is `rproxy`. So the app must trust
+address added to `X-Forwarded-For`, from a TCP peer that is `rproxy`. So the app
-`rproxy`'s address for forwarded headers. In a container of its own, `rproxy` is
+must trust `rproxy`'s address for forwarded headers. In a container of its own,
-on the private network, which the usual default of a trusted-proxy setting
+`rproxy` is on the private network, which the usual default of a trusted-proxy
-covers. Beside the app, its address is `127.0.0.1` or `::1`, which the private
+setting covers. Beside the app, its address is `127.0.0.1` or `::1`, which the
-ranges leave out, so the app's own setting must name them too, as `app.run`
+private ranges leave out, so the app's own setting must name them too, as
-does.
+`app.run` does.
 
 ### Checking that it works
 
@@ -168,9 +197,9 @@ does.
   `healthy` for each container of `smallwebwaf`.
 - A log line with `"msg":"starting"` gives the version, the address and every
   setting in effect, with secrets masked.
-- A request to the site through traefik gets the app's answer.
+- A request to the site through the reverse proxy in front gets the app's
-  `https://<site>/_sww/healthz` answers `ok`. `waf`'s log lines about the
+  answer. `https://<site>/_sww/healthz` answers `ok`. `waf`'s log lines about
-  request have `"action":"forward"`.
+  the request have `"action":"forward"`.
 - To see a refusal without banning yourself, run `waf` with
   `SWW_WAF_MODE=observe` and ask for `/.env`. The request reaches the app.
   `waf`'s log lines have `"would_action":"temporarily_banned"` and
@@ -540,9 +569,10 @@ request reaches the app.
 A refused visitor is answered with `SWW_WAF_BAN_RESPONSE`. A `block` rule or a
 Core Rule Set match answers `403` and bans nobody, since the Core Rule Set has
 false positives; such refusals count toward `SWW_WAF_REFUSALS_LIMIT_PER_MINUTE`
-instead. A request over the header limits of step 3 is answered `431`, and bans
+instead. A request over the header limits of step 3 is answered `414` for a
-nobody either. `rproxy` itself answers `405` to a method it does not pass on,
+request line over 8 KiB and `431` otherwise. It bans nobody either. `rproxy`
-and the status for a size or time limit, such as `413` for a body too large.
+itself answers `405` to a method it does not pass on, and the status for a size
+or time limit, such as `413` for a body too large.
 
 ### Clients and bans
 

SPEC.md

@@ -3,7 +3,8 @@
 `smallwebwaf` is a web application firewall for self-hosted apps. It is one
 binary, `sww`, and two of its commands do the work:
 
-- `sww rproxy` is a reverse proxy between traefik and one app.
+- `sww rproxy` is a reverse proxy between one app and the reverse proxy that
+  terminates TLS.
 - `sww waf` decides what happens to each request, for many sites.
 
 This document says what it must do and why, each requirement once. Everything in
@@ -45,7 +46,8 @@ never as a time.
 
 ## Non-goals
 
-- TLS, certificates and routing by host name. Those are traefik's job.
+- TLS, certificates and routing by host name. Those are the job of the reverse
+  proxy in front of `rproxy`, such as traefik, nginx or Caddy.
 - More than one app behind one `rproxy`. Each app has its own.
 - Browser challenges such as captchas or proof of work. If wanted, chain Anubis
   between `rproxy` and the app.
@@ -151,11 +153,11 @@ field gives that name. `refusal_limit` and `byte_limits` give theirs in
       around its address, a /64 by default, since one abuser usually controls a
       whole /64. A client is therefore one IPv4 address or one IPv6 group.
 3. The header limits (`header_limits`; see "Answering in time"). They come first
-   after `SWW_WAF_ALLOW_NETS`, since they only count header fields and cookies.
+   after `SWW_WAF_ALLOW_NETS`, since they only measure lines and count header
-   Next, the tag lists (`tag_lists`; see "Request tags"). Each list that holds
+   fields and cookies. Next, the tag lists (`tag_lists`; see "Request tags").
-   the client adds its tag. Next, `routewatch_tags` adds the client's `asn=` and
+   Each list that holds the client adds its tag. Next, `routewatch_tags` adds
-   `prefix=` tags while `SWW_WAF_ROUTEWATCH_URL` is set. A client in
+   the client's `asn=` and `prefix=` tags while `SWW_WAF_ROUTEWATCH_URL` is set.
-   `SWW_WAF_ALLOW_NETS` skips the header limits and gets no tag.
+   A client in `SWW_WAF_ALLOW_NETS` skips the header limits and gets no tag.
 4. The static lists. A client in `SWW_WAF_ALLOW_NETS` skips steps 5 to 15, the
    byte limits and the refusal limit. A client in `SWW_WAF_DENY_NETS` is refused
    (`deny_nets`); a client in both lists is let through.
@@ -252,9 +254,9 @@ does not reach neighbours who did nothing. Requests refused under a ban are not
 counted against limits. They are counted in the client's history and in the
 ban's notes.
 
-A request over the header limits is refused with `431` before the bans are
+A request over the header limits is refused with `414` or `431` before the bans
-checked (see "Answering in time"). It makes no ban, makes no ban permanent and
+are checked (see "Answering in time"). It makes no ban, makes no ban permanent
-is not counted in a ban's notes.
+and is not counted in a ban's notes.
 
 An offence is a request `waf` holds against the client. It is one of:
 
@@ -1943,10 +1945,10 @@ leave out a cookie only when its name matches exactly, case included.
 ### Ban lengths, response and scope
 
 `SWW_WAF_BAN_RESPONSE` is `403` by default, which makes a ban easy to recognise
-when debugging; `429` and `close` are the alternatives. Behind traefik, `close`
+when debugging; `429` and `close` are the alternatives. `close` does not leave
-does not leave the client unanswered: traefik answers `502`, as it does whenever
+the client unanswered: the reverse proxy in front answers `502`, as it does
-its backend drops a connection. `SWW_WAF_BAN_SCOPE_V4_PREFIX` widens an IPv4 ban
+whenever its backend drops a connection. `SWW_WAF_BAN_SCOPE_V4_PREFIX` widens an
-to the surrounding netblock. The four ban lengths are under "Bans".
+IPv4 ban to the surrounding netblock. The four ban lengths are under "Bans".
 
 ### Reputation
 
@@ -2381,7 +2383,7 @@ answer but the last below carries `X-Sww-Disposition`.
   of:
     - `SWW_WAF_BAN_RESPONSE`, for a refusal;
     - `403`, for a `block` rule or the Core Rule Set;
-    - `431`, for a request over the header limits;
+    - `414` or `431`, for a request over the header limits;
     - `404`, for a path under `/_sww/` that passes the checks, so that the app
       never sees that prefix.
 - `X-Sww-Disposition: close`, status `200`, no body. This takes the place of a
@@ -2442,22 +2444,31 @@ never wait. These can still wait for GeoJS:
 - a rule file;
 - the Core Rule Set.
 
-The header limits are fixed, with no setting. `waf` refuses a request over
+The header limits are fixed, with no setting. A line's length is in bytes and
-either one:
+does not count its line ending. `waf` refuses a request whose request line is
+longer than 8 KiB with `414`. An example is `GET /search?q=` followed by 30,000
+characters.
 
+It refuses a request with `431` for any of:
+
+- a header line longer than 8 KiB. Each value of a header sent twice is a line
+  of its own. `Host` counts as a line.
 - more than 50 cookies. Each part of its `Cookie` headers between semicolons
   counts as one, unless it is empty or only spaces and tabs.
 - more than 100 header fields. A header sent twice counts twice. `Host` and
   `Transfer-Encoding` do not count. `X-Request-ID` and `X-Forwarded-Proto` do.
 
-Real clients never reach these limits. The answer is `deny` with `431`, and the
+Real clients rarely reach these limits. nginx refuses lines over 8 KiB by
-log line's action is `request_header_too_large`. The refusal makes no ban and is
+default, and Apache's default limit is about the same. The answer is `deny`. The
-no offence.
+log line's action is `request_line_too_long` for `414` and
+`request_header_too_large` for `431`. The refusal makes no ban and is no
+offence.
 
 The header limits are the first check after `SWW_WAF_ALLOW_NETS`. A request over
 them is refused before any later check runs. So it causes no lookup, no query to
 an outside source and no rule match, and the rate limits do not count it. A
-client under a ban or in `SWW_WAF_DENY_NETS` also gets `431` for such a request.
+client under a ban or in `SWW_WAF_DENY_NETS` also gets `414` or `431` for such a
+request.
 
 The limits apply on every path and in every `SWW_WAF_CORE_RULE_SET_MODE`. A
 client in `SWW_WAF_ALLOW_NETS` skips them, as it skips the Core Rule Set. In
@@ -2465,9 +2476,10 @@ client in `SWW_WAF_ALLOW_NETS` skips them, as it skips the Core Rule Set. In
 other check runs on it.
 
 The Core Rule Set runs each of its rules on each cookie, so thousands of small
-cookies would keep it busy for over a second. Within the limits, one long cookie
+cookies would keep it busy for over a second. One 30 KB cookie or query string
-or query string can still keep it busy for a fraction of a second. So enough
+would keep it busy for a third of a second or more. A request with several long
-such requests at once can overload `waf` past
+`Cookie` lines, each within the limits, can keep it as busy. Enough such
+requests at once can still overload `waf` past
 `SWW_RPROXY_WAF_BACKEND_TIMEOUT_MS`.
 
 ### The report
@@ -2761,9 +2773,10 @@ its whole body. The visitor gets that answer at once, and the connection closes
 after it.
 
 The largest request line and headers is 32 KiB. A kept-open connection is closed
-after 120 seconds idle. Neither has a setting. traefik, by default, closes an
+after 120 seconds idle. Neither has a setting. The reverse proxy in front should
-unused connection after 90 seconds. So traefik closes first, and never sends a
+close an unused connection sooner, so that it never sends a request on a
-request on a connection `rproxy` is closing.
+connection `rproxy` is closing. traefik closes one after 90 seconds by default.
+nginx, by default, opens a new connection for each request.
 
 What the visitor gets when a limit is passed:
 
@@ -2814,14 +2827,16 @@ chooses: `waf` runs `waf`, and with it unset the image runs `rproxy`.
 The usual setup is three containers on one private network:
 
 - the app;
-- `rproxy`, which traefik routes to, with `SWW_RPROXY_UPSTREAM_URL` naming the
+- `rproxy`, which the reverse proxy that terminates TLS forwards to, with
-  app and `SWW_RPROXY_WAF_BACKEND` naming `waf`;
+  `SWW_RPROXY_UPSTREAM_URL` naming the app and `SWW_RPROXY_WAF_BACKEND` naming
+  `waf`;
 - `waf`, with `SWW_COMMAND=waf` and a volume for its state files.
 
 Each further app adds its own container and its own `rproxy`, whose
 `SWW_RPROXY_WAF_BACKEND` names the same `waf` (see "Sites"). Anything on that
 network can reach an app around `rproxy`, and can ask `waf` questions or send it
-reports. So the network holds only what you trust.
+reports. So the network holds only what you trust. "The reverse proxy in front"
+in `README.md` lists what that proxy must do.
 
 ### `rproxy` in the app's container
 
@@ -2893,10 +2908,10 @@ process that stops at start is started again every second, not in a tight loop.
   container's output, which `docker logs` shows.
 - When a service exits, runit runs its `run` script again, and the container
   does not stop. Beside an app, the other process keeps running.
-- While `rproxy` is down, traefik answers `502`. While the app is down, `rproxy`
+- While `rproxy` is down, the reverse proxy in front answers `502`. While the
-  answers `502`, which is not a client offence. While `waf` is down,
+  app is down, `rproxy` answers `502`, which is not a client offence. While
-  `SWW_RPROXY_WAF_BACKEND_NO_ANSWER_DISPOSITION` decides (see "Without an answer
+  `waf` is down, `SWW_RPROXY_WAF_BACKEND_NO_ANSWER_DISPOSITION` decides (see
-  from `waf`").
+  "Without an answer from `waf`").
 - Only faults found at start stop `waf`:
     - invalid configuration;
     - a lookup database that is missing or unreadable;
@@ -2929,23 +2944,26 @@ checks:
 - With `SWW_COMMAND` unset, empty or `rproxy`, it passes while `rproxy` answers
   that request on `127.0.0.1`, at the port in `SWW_RPROXY_LISTEN_ADDR`, and the
   app accepts connections at `SWW_RPROXY_UPSTREAM_URL`. It does not ask `waf`,
-  so that the site stays in traefik's routes while `waf` is down.
+  so that the site stays in the routes of the reverse proxy in front while `waf`
+  is down.
 - With any other value, it fails with a message naming `SWW_COMMAND` and its
   value.
 
-traefik sends a container no requests until it shows as healthy. So the check
+A reverse proxy that reads Docker's health status, as traefik does, sends a
-runs every second from the container's start until it first passes, for up to a
+container no requests until it shows as healthy. So the check runs every second
-minute, and every 30 seconds after that. An app with a health check of its own
+from the container's start until it first passes, for up to a minute, and every
-can replace the image's `HEALTHCHECK` with one that checks both.
+30 seconds after that. An app with a health check of its own can replace the
+image's `HEALTHCHECK` with one that checks both.
 
 ### Ports
 
 `rproxy` listens on no port but the one in `SWW_RPROXY_LISTEN_ADDR`, 8080 by
-default, which traefik routes to. It passes requests to the app at
+default, which the reverse proxy in front forwards to. It passes requests to the
-`SWW_RPROXY_UPSTREAM_URL`, `http://127.0.0.1:8081` by default. Another port may
+app at `SWW_RPROXY_UPSTREAM_URL`, `http://127.0.0.1:8081` by default. Another
-be set: the health check follows the setting, and traefik's port label
+port may be set: the health check follows the setting, and the reverse proxy in
-(`traefik.http.services.<name>.loadbalancer.server.port`) must name it. An app
+front must name it, as traefik's port label
-beside `rproxy` must leave that port free.
+(`traefik.http.services.<name>.loadbalancer.server.port`) does. An app beside
+`rproxy` must leave that port free.
 
 `waf` listens on no port but the one in `SWW_WAF_LISTEN_ADDR`, 8080 by default.
 The questions, the reports and its own endpoints all come there.
@@ -2986,9 +3004,9 @@ in `docs/settings.md` shows the commands.
 ### Forwarded headers
 
 The app's TCP peer is `rproxy`, and the `X-Forwarded-For` the app receives ends
-with traefik's address, which `rproxy` adds after the visitor's. So the app must
+with the address of the reverse proxy in front, which `rproxy` adds after the
-trust `rproxy`'s address for forwarded headers, besides the private address
+visitor's. So the app must trust `rproxy`'s address for forwarded headers,
-ranges traefik is on.
+besides the private address ranges that proxy is on.
 
 - In a container of its own, `rproxy`'s address is on the private network. The
   usual default for a trusted-proxy setting, the private ranges, covers it.

docs/request-log.md

@@ -68,7 +68,8 @@ Every one of these lines has:
 ### Request detail
 
 - `request_id`: the id `rproxy` made for the request when it arrived.
-- `peer_ip`: the address of `rproxy`'s TCP peer, normally traefik.
+- `peer_ip`: the address of `rproxy`'s TCP peer, normally the reverse proxy in
+  front of it.
 - `forwarded_for`: the `X-Forwarded-For` header the visitor's request came with.
 - `client_group`: the client as rate limiting counts it, an IPv4 address as a
   /32 or an IPv6 group.
@@ -102,7 +103,8 @@ Every one of these lines has:
       ban this request made or made permanent;
     - `country_denied`, `client_is_rate_limited`, `blocked_by_block_rule` and
       `blocked_by_core_rule_set`: refused by that check;
-    - `request_header_too_large`: over a header limit;
+    - `request_line_too_long`: a request line over the header limits;
+    - `request_header_too_large`: headers over the header limits;
     - `own_endpoint`: answered at one of `waf`'s own endpoints, or `404` for a
       path under `/_sww/`.
 - `would_action`: in `observe` mode, what `enforce` mode would have done with a
@@ -124,7 +126,10 @@ Every one of these lines has:
     - `rate_limits`: `window`, `count` and `limit`;
     - `trap_paths`: `path`, the trap path asked for;
     - `rule_files`: `rule_id` and `rule_action`, of the rule that refused it;
-    - `header_limits`: `fields`, `fields_limit`, `cookies` and `cookies_limit`;
+    - `header_limits`: for a request line, `request_line_bytes` and
+      `request_line_bytes_limit`; for headers, `longest_header_line_bytes`,
+      `header_line_bytes_limit`, `fields`, `fields_limit`, `cookies` and
+      `cookies_limit`;
     - `core_rule_set`: `score`, and `threshold`,
       `SWW_WAF_CORE_RULE_SET_SCORE_THRESHOLD`;
     - `refusal_limit`: `window`, `count` and `limit`, of the refusal limit;

docs/settings.md

@@ -423,8 +423,9 @@ A few limits are fixed rather than settings:
 - at most 20,000 anomaly counters are kept;
 - each alert destination's queue holds at most 1,000 alerts;
 - `waf` holds at most 10,000 answered requests awaiting their reports;
-- `waf` refuses a request with more than 50 cookies or more than 100 header
+- `waf` refuses a request with a request line or header line over 8 KiB, more
-  fields (see "Answering in time" under "`waf`" in [`SPEC.md`](../SPEC.md));
+  than 50 cookies or more than 100 header fields (see "Answering in time" under
+  "`waf`" in [`SPEC.md`](../SPEC.md));
 - `rproxy` takes a request line and headers of at most 32 KiB, and closes a
   kept-open connection idle for 120 seconds;
 - `rproxy` reads at most 1 MiB of the body of `waf`'s answer, and answers `502`
@@ -477,9 +478,9 @@ start, and an invalid value stops the start. Any can be given as a file, as a
   `10.0.0.0/8,172.16.0.0/12,192.168.0.0/16`): the netblocks whose
   `X-Forwarded-For` is believed. Set but empty, it trusts nothing. A client
   outside these netblocks cannot claim another address. Where other containers
-  reach `rproxy` directly, or visitors on a private network reach traefik, they
+  reach `rproxy` directly, or visitors on a private network reach the reverse
-  can name another address in the header. Narrowing the setting to traefik's own
+  proxy in front, they can name another address in the header. Narrowing the
-  network closes that gap.
+  setting to that proxy's own network closes that gap.
 
 ## The image's command
 

internal/requestlog/requestlog.go

@@ -21,7 +21,12 @@ const (
 	// the app.
 	ActionForward = "forward"
 
-	// ActionRequestHeaderTooLarge is a request over the header limits.
+	// ActionRequestLineTooLong is a request whose request line is too long for
+	// the header limits.
+	ActionRequestLineTooLong = "request_line_too_long"
+
+	// ActionRequestHeaderTooLarge is a request whose headers are over the
+	// header limits.
 	ActionRequestHeaderTooLarge = "request_header_too_large"
 
 	// ActionClientIsRateLimited is a request refused because it took its
@@ -143,7 +148,7 @@ type Line struct {
 	// taken with a request it would have refused: ActionClientDenied,
 	// ActionTemporarilyBanned, ActionPermanentlyBanned, ActionCountryDenied,
 	// ActionClientIsRateLimited, ActionBlockedByBlockRule,
-	// ActionBlockedByCoreRuleSet, or, in waf,
+	// ActionBlockedByCoreRuleSet, or, in waf, ActionRequestLineTooLong or
 	// ActionRequestHeaderTooLarge for the header limits.
 	WouldAction string `json:"would_action,omitempty"`
 	// Heuristic is the name of the heuristic that refused the request, in

internal/waf/answertime_test.go

@@ -39,6 +39,7 @@ const (
 	// The header limits SPEC.md gives.
 	cookieLimit      = 50
 	headerFieldLimit = 100
+	lineLimit        = 8192
 	// cookieHeader is the header the cookie limit counts.
 	cookieHeader = "Cookie"
 	// tooLarge is how waf refuses a request over the header limits.
@@ -104,11 +105,139 @@ func TestHeaderLimitRefusalNamesItsHeuristicCountsAndLimits(t *testing.T) {
 	fillHeaders(req, headerFieldLimit+1)
 	do(t, req)
 
+	// The longest header line is X-Request-ID's, with its 26-character id.
 	wantHeuristic(
 		t,
 		s.out.requestLine(t),
 		"header_limits",
-		`{"fields": 101, "fields_limit": 100, "cookies": 0, "cookies_limit": 50}`,
+		`{"longest_header_line_bytes": 40, "header_line_bytes_limit": 8192,
+		"fields": 101, "fields_limit": 100, "cookies": 0, "cookies_limit": 50}`,
+	)
+}
+
+// longQuery returns a path whose request line, sent by Go's client as
+// "GET <path> HTTP/1.1", is lineBytes long.
+func longQuery(lineBytes int) string {
+	const around = len("GET /?q= HTTP/1.1")
+
+	return "/?q=" + strings.Repeat("a", lineBytes-around)
+}
+
+func TestARequestLineOverTheLimitIsRefusedWith414BeforeAnyOtherCheck(
+	t *testing.T,
+) {
+	t.Parallel()
+
+	for _, tc := range []struct {
+		name      string
+		lineBytes int
+		// cookies is how many cookies the request carries.
+		cookies int
+		status  int
+		action  string
+	}{
+		{
+			"at the limit", lineLimit, 0, http.StatusOK,
+			requestlog.ActionForward,
+		},
+		{
+			"over the limit", lineLimit + 1, 0, http.StatusRequestURITooLong,
+			requestlog.ActionRequestLineTooLong,
+		},
+		{
+			"over the limit and the cookie limit", lineLimit + 1,
+			cookieLimit + 1, http.StatusRequestURITooLong,
+			requestlog.ActionRequestLineTooLong,
+		},
+	} {
+		t.Run(tc.name, func(t *testing.T) {
+			t.Parallel()
+
+			s := startWAF(t, "", map[string]string{coreRuleSetMode: block})
+			req := s.question(siteA, client, longQuery(tc.lineBytes))
+
+			if tc.cookies > 0 {
+				req.Header.Set(cookieHeader, cookies(tc.cookies))
+			}
+
+			got := do(t, req)
+			line := s.out.requestLine(t)
+
+			if tc.status == http.StatusOK {
+				wantDisposition(t, got, tc.status, waf.DispositionAllow)
+			} else {
+				wantDisposition(t, got, tc.status, waf.DispositionDeny)
+			}
+
+			wantLine(t, line, tc.status, tc.action)
+
+			refused := tc.status != http.StatusOK
+			if refused != (line.DurationCoreRuleSetMS == nil) {
+				t.Errorf(
+					"Core Rule Set time %v for a request refused: %t",
+					line.DurationCoreRuleSetMS,
+					refused,
+				)
+			}
+		})
+	}
+}
+
+func TestAHeaderLineOverTheLimitIsRefusedWith431(t *testing.T) {
+	t.Parallel()
+
+	for _, tc := range []struct {
+		name string
+		make func(*http.Request)
+		// refused is true for a request over the limit, and false for one at it.
+		refused bool
+	}{
+		{"a header line at the limit", func(req *http.Request) {
+			req.Header.Set("X-Long", strings.Repeat("a", lineLimit-len("X-Long: ")))
+		}, false},
+		{"a header line over the limit", func(req *http.Request) {
+			req.Header.Set("X-Long", strings.Repeat("a", lineLimit+1-len("X-Long: ")))
+		}, true},
+		{"one cookie over the limit", func(req *http.Request) {
+			req.Header.Set(cookieHeader, "a="+strings.Repeat("a", lineLimit))
+		}, true},
+		{"a Host line over the limit", func(req *http.Request) {
+			req.Host = strings.Repeat("a", lineLimit+1-len("Host: "))
+		}, true},
+		{"a header sent twice, each line within the limit", func(req *http.Request) {
+			req.Header.Add("X-Long", strings.Repeat("a", 8000))
+			req.Header.Add("X-Long", strings.Repeat("a", 8000))
+		}, false},
+	} {
+		t.Run(tc.name, func(t *testing.T) {
+			t.Parallel()
+
+			s := startWAF(t, "", nil)
+			req := s.question(siteA, client, "/")
+			tc.make(req)
+
+			got := do(t, req)
+
+			if tc.refused {
+				wantDisposition(t, got, tooLarge, waf.DispositionDeny)
+			} else {
+				wantDisposition(t, got, http.StatusOK, waf.DispositionAllow)
+			}
+		})
+	}
+}
+
+func TestRequestLineRefusalNamesItsHeuristicLengthAndLimit(t *testing.T) {
+	t.Parallel()
+
+	s := startWAF(t, "", nil)
+	do(t, s.question(siteA, client, longQuery(lineLimit+1)))
+
+	wantHeuristic(
+		t,
+		s.out.requestLine(t),
+		"header_limits",
+		`{"request_line_bytes": 8193, "request_line_bytes_limit": 8192}`,
 	)
 }
 

internal/waf/headerlimits.go

@@ -10,16 +10,22 @@ import (
 	"sneak.berlin/go/smallwebwaf/internal/requestlog"
 )
 
-// The header limits: the most cookies and header fields a request may have.
+// The header limits: the most cookies and header fields a request may have,
-// Real clients never reach them.
+// and the longest its request line and each header line may be, in bytes, not
+// counting the line ending. Real clients rarely reach them. maxLineBytes is
+// what nginx allows by default.
 const (
 	maxCookies      = 50
 	maxHeaderFields = 100
+	maxLineBytes    = 8 << 10
 )
 
-// headerLimits refuses a request with more than maxHeaderFields header fields
+// headerLimits refuses a request with a request line longer than maxLineBytes,
-// or more than maxCookies cookies, with 431. Its figures are the request's
+// with 414. It refuses a request with a header line longer than maxLineBytes,
-// header fields and cookies, and the limit of each.
+// more than maxHeaderFields header fields or more than maxCookies cookies, with
+// 431. Its figures are the request line's length and its limit for 414. For
+// 431 they are the longest header line, the header fields and the cookies,
+// each with its limit.
 type headerLimits struct{}
 
 func (headerLimits) name() string { return "header_limits" }
@@ -29,20 +35,59 @@ func (headerLimits) check(
 	rq *request,
 	_ time.Time,
 ) *verdict {
+	requestLine := rq.requestLineBytes()
+	if requestLine > maxLineBytes {
+		return &verdict{
+			action: requestlog.ActionRequestLineTooLong,
+			figures: map[string]any{
+				"request_line_bytes":       requestLine,
+				"request_line_bytes_limit": maxLineBytes,
+			},
+		}
+	}
+
+	longest := rq.longestHeaderLineBytes()
 	fields, cookies := rq.headerCounts()
-	if fields <= maxHeaderFields && cookies <= maxCookies {
+
+	if longest <= maxLineBytes && fields <= maxHeaderFields &&
+		cookies <= maxCookies {
 		return nil
 	}
 
 	return &verdict{
 		action: requestlog.ActionRequestHeaderTooLarge,
 		figures: map[string]any{
+			"longest_header_line_bytes": longest,
+			"header_line_bytes_limit":   maxLineBytes,
 			"fields":                    fields, "fields_limit": maxHeaderFields,
 			"cookies": cookies, "cookies_limit": maxCookies,
 		},
 	}
 }
 
+// requestLineBytes returns the length of the request's request line, such as
+// "GET /search?q=x HTTP/1.1", not counting its line ending. The target is the
+// one the visitor sent, which rproxy's question carries unchanged.
+func (rq *request) requestLineBytes() int {
+	return len(rq.in.Method) + len(" ") + len(rq.in.RequestURI) +
+		len(" ") + len(rq.in.Proto)
+}
+
+// longestHeaderLineBytes returns the length of the request's longest header
+// line, such as "Cookie: a=1", not counting its line ending. Each value of a
+// header sent twice is a line of its own, and Host is a line too.
+func (rq *request) longestHeaderLineBytes() int {
+	longest := len("Host: ") + len(rq.in.Host)
+
+	for name, values := range rq.in.Header {
+		for _, value := range values {
+			longest = max(longest, len(name)+len(": ")+len(value))
+		}
+	}
+
+	return longest
+}
+
 // headerCounts returns the request's header fields, each value of a header sent
 // twice being one, and its cookies, each part of a Cookie header between
 // semicolons being one unless it is empty or only spaces and tabs. The Core

internal/waf/heuristics.go

@@ -41,8 +41,8 @@ const (
 
 // beforeLookup are the heuristics that run before the client's AS number and
 // country are looked up, so that a client they refuse is not looked up.
-// header_limits comes first: it only counts, and a request it refuses causes no
+// header_limits comes first: it only measures and counts, and a request it
-// other work.
+// refuses causes no other work.
 func beforeLookup() []heuristic {
 	return []heuristic{
 		headerLimits{},

internal/waf/request.go

@@ -177,7 +177,7 @@ func requestHeaders(r *http.Request, names []string) map[string]string {
 // check is the one place where a request can be refused. It returns nil to let
 // the request through. The heuristics of checkClient decide: a request they
 // refuse is answered with SWW_WAF_BAN_RESPONSE, 403 for a block rule or the Core
-// Rule Set, or 431 for the header limits. In observe mode nothing is refused,
+// Rule Set, or 414 or 431 for the header limits. In observe mode nothing is refused,
 // and the log line names what enforce mode would have done. ctx is the
 // request's own context.
 func (rq *request) check(ctx context.Context) *refusal {
@@ -196,6 +196,8 @@ func (rq *request) check(ctx context.Context) *refusal {
 	case action == requestlog.ActionBlockedByBlockRule ||
 		action == requestlog.ActionBlockedByCoreRuleSet:
 		return &refusal{status: http.StatusForbidden, action: action}
+	case action == requestlog.ActionRequestLineTooLong:
+		return &refusal{status: http.StatusRequestURITooLong, action: action}
 	case action == requestlog.ActionRequestHeaderTooLarge:
 		return &refusal{
 			status: http.StatusRequestHeaderFieldsTooLarge,

internal/waf/waf_test.go

@@ -1690,7 +1690,12 @@ func TestALargeBodyAnnouncedAndLongHeadersAreNoReasonToRefuse(t *testing.T) {
 		strings.NewReader("a body"))
 	req.Header.Set(waf.ContentLengthHeader, "1073741824")
 	req.Header.Set(forwardedFor, otherClient)
-	req.Header.Set("X-Long", strings.Repeat("x", 40<<10))
+
+	// 40,000 bytes of headers, over rproxy's 32 KiB, in lines within the
+	// header limits.
+	for i := range 5 {
+		req.Header.Set("X-Long-"+strconv.Itoa(i), strings.Repeat("x", 8000))
+	}
 
 	got := do(t, req)
 	wantDisposition(t, got, http.StatusOK, waf.DispositionAllow)