servewaf answers rproxy's question about each request and takes its report (closes #170)

`smallwebwaf servewaf` runs today's checks on the visitor's request each
question carries, answers rproxy, and passes nothing to an app. rproxy reports
every request servewaf answered. A report counts an allowed request's bytes and
writes servewaf's second log line. The table holds a copy of what a report
needs, never the request, so a report cannot reach a request being handled.

Judgement call: a question's body is read before any check; over 64 KiB gets 400.
Judgement call: a report's bytes and durations have ceilings, so they cannot overflow.
Judgement call: a `close` disposition for SWWAF_BAN_RESPONSE=close.

Model: opus-5-5

docs/admin-endpoints.md

@@ -46,3 +46,8 @@ curl -H "Authorization: Bearer $TOKEN" -X DELETE \
 curl -H "Authorization: Bearer $TOKEN" \
     https://app.example/_smallwebwaf/clients/203.0.113.9
 ```
+
+## `servewaf`
+
+`smallwebwaf servewaf` answers these endpoints at its own address. No check runs
+on those requests (see "`servewaf`" in [`SPEC.md`](../SPEC.md)).

docs/alerts.md

@@ -78,6 +78,9 @@ on one line:
 
 - `instance`: `SWWAF_INSTANCE_NAME`. `time`: when the alert was raised. `event`:
   one of the events above.
+- `host`: the site of the request that raised the alert. Only `servewaf` sends
+  this field, since it serves many sites, and not for `source_failure`,
+  `file_error` and `summary`.
 - `client`: the address whose request raised the alert. Empty for
   `source_failure`, `file_error` and `summary`.
 - `netblock`: empty for `source_failure`, `file_error` and `summary`; otherwise
@@ -110,7 +113,7 @@ Slack and ntfy get a message with a title and a text. The title is the instance
 and the event, such as `fsn1app1/gitea: ban`. The text is the `reason`, then one
 line for each of these that the alert has:
 
-- the client, the netblock and the country;
+- the host, the client, the netblock and the country;
 - the file, the source, the error and the mode from `detail`;
 - the suppressed repeats, if any.
 

docs/metrics.md

@@ -79,3 +79,14 @@ By `file`:
   `smallwebwaf_alerts_failed_total`, `smallwebwaf_alerts_suppressed_total` and
   `smallwebwaf_alerts_dropped_total`;
 - Go's own `go_` metrics and the process's `process_` metrics.
+
+## `servewaf`
+
+`smallwebwaf servewaf` counts a denied request at its decision. It counts an
+allowed request when its report comes, with the status, bytes and times the
+report gives. These are not counted:
+
+- a report itself;
+- an allowed request whose report never comes;
+- a question refused with `400`;
+- a question whose body stopped arriving.

docs/request-log.md

@@ -117,3 +117,66 @@ All in milliseconds:
   connection;
 - `duration_upstream_first_byte`: until the first byte of the answer;
 - `duration_upstream_total`: until the end of the answer.
+
+## `servewaf`'s lines
+
+`smallwebwaf servewaf` writes two lines for each question it answers, joined by
+`request_id`. The field `servewaf_line` says which of the two a line is:
+
+- `decision`: the line it writes once it has answered the question;
+- `report`: the line it writes when `rproxy`'s report comes, with everything
+  known. The repetition is intended.
+
+A request to its own endpoints writes one line, without `servewaf_line`. A
+report writes no line but the `report` line of the request it names.
+
+These questions write no line:
+
+- a question refused with `400` (see "The question" under "`servewaf`" in
+  [`SPEC.md`](../SPEC.md));
+- a question whose body stopped arriving, which gets no answer.
+
+### The `decision` line
+
+It has the fields above, with these meanings where they differ:
+
+- `client_ip`: `X-Smallwebwaf-Client`.
+- `peer_ip`: `X-Smallwebwaf-Peer`.
+- `host`: the site the visitor asked for.
+- `protocol`: the question's own, `HTTP/1.1`.
+- `content_length`: `X-Smallwebwaf-Content-Length`.
+- `request_id`: the question's `X-Request-ID`.
+- `status`: what `servewaf` answered: `200` for `allow`, the status of `deny`,
+  or `0` for `close`, as the visitor is then sent nothing.
+- `request_bytes`: how much of the question's body the Core Rule Set read.
+- `response_bytes`: the body of `servewaf`'s answer.
+- `action`: `forward` for `allow`, and `admin` for the `404` for a path under
+  `/_smallwebwaf/`.
+- `aborted`: true when `rproxy` went away before the answer.
+- `duration_total`: from `servewaf` having read the question's body to the line.
+- `time`: when `servewaf` had read the question's body.
+
+The line leaves out `upstream_status`, `websocket` and the
+`duration_upstream_...` fields, since `servewaf` passes nothing to the app.
+
+The bytes of an allowed request are counted when its report comes. So `counts`
+holds the client's bytes without this request's.
+
+### The `report` line
+
+It has every field of the `decision` line, and `time` stays as the `decision`
+line gives it. These fields say what the report says:
+
+- `status`: what the visitor got, `0` if nothing;
+- `request_bytes` and `response_bytes`: the body bytes each way, with what a
+  WebSocket carried each way;
+- `duration_total`: from the request's headers being read by `rproxy` to the end
+  of the answer;
+- `duration_upstream_total`: from the hand-over to the app to the end of the
+  answer, for an allowed request.
+
+For an allowed request, the report's counting also changes these fields:
+
+- `counts`: the byte totals now include this request's;
+- `limit_hit`, `offence` and `ban_expires`: set when the report's bytes broke a
+  byte limit.

docs/settings.md

@@ -339,4 +339,22 @@ A few limits are fixed rather than settings:
 - at most 100,000 DNS blocklist verdicts and 100,000 AbuseIPDB scores are kept;
 - at most 1,000 DNS blocklist queries are under way at once;
 - at most 20,000 anomaly counters are kept;
-- each alert destination's queue holds at most 1,000 alerts.
+- each alert destination's queue holds at most 1,000 alerts;
+- `servewaf` holds at most 10,000 answered requests awaiting their reports.
+
+## `servewaf`
+
+`smallwebwaf servewaf` uses every setting here but these, which it ignores:
+
+- `SWWAF_UPSTREAM_URL` and `SWWAF_TRUSTED_PROXIES`;
+- the five timeouts under "Size and time limits";
+- `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES`, `SWWAF_REQUEST_MAX_BYTES` and
+  `SWWAF_RESPONSE_MAX_BYTES`.
+
+An invalid value of one of these still stops the start, and the line of settings
+at start still shows them.
+
+`SWWAF_ADD_LOOKUP_HEADERS` puts the headers on the answer to `rproxy`, not on a
+request to an app. `SWWAF_WAF_BODY_LIMIT` has an effect up to 64 KiB less one
+byte, whatever its value. A question carries no more of a body than 64 KiB (see
+"`servewaf`" in [`SPEC.md`](../SPEC.md)).