README and SPEC say a client too slow to send its request line and headers may get an error answer (closes #138)

A client too slow to send its request line and headers within
SWWAF_CLIENT_REQUEST_TIMEOUT gets either no answer or an error answer
from Go's server, mostly 400 Bad Request; either way its connection is
closed, nothing reaches the app, and no request log line is written.
The README's "Request log" and SPEC's size and time limits said such a
client always gets no answer. Both documents' summaries of
smallwebwaf's own answers now cover only limits passed after the
request line and headers have been read, and give 408 only for a slow
body; SPEC names Go's server as the one answering 431.

Model: opus-5-5

SPEC.md

@@ -414,10 +414,10 @@ The settings, by group:
       to send its request line and headers, and then, from the end of the
       headers, its body.
     - `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` (default `32K`): the largest
-      request line and headers a client may send. Over it, `smallwebwaf` answers
-      `431` and closes the connection, and nothing reaches the app. It must be
-      more than `4K`, and cannot be `off`: Go's HTTP server always has such a
-      limit, and reads 4 KiB past the one it is given before it refuses.
+      request line and headers a client may send. Over it, Go's HTTP server
+      answers `431` and closes the connection, and nothing reaches the app. It
+      must be more than `4K`, and cannot be `off`: Go's HTTP server always has
+      such a limit, and reads 4 KiB past the one it is given before it refuses.
     - `SWWAF_CLIENT_IDLE_TIMEOUT` (default `120s`): how long a kept-open
       connection may wait for its next request before `smallwebwaf` closes it.
       It is longer than the 90 seconds after which traefik, by default, closes a
@@ -435,12 +435,13 @@ The settings, by group:
       the client sends it and the app receives it.
     - `SWWAF_RESPONSE_MAX_BYTES` (default `5G`): the largest response body, as
       the app sends it and the client receives it.
-    - When a limit is passed before the response has started, `smallwebwaf`
-      answers itself: `413` for a request body that is too large, `408` for a
-      client that is too slow, `502` for a response that is too large, `504` for
-      an app that is too slow. A request that announces a body larger than its
-      limit is refused before anything reaches the app. Once the response has
-      started it can only be cut off, and the connection is closed.
+    - When a limit is passed after a request's line and headers have been read,
+      but before the response has started, `smallwebwaf` answers itself: `413`
+      for a request body that is too large, `408` for a client too slow to send
+      its body, `502` for a response that is too large, `504` for an app that is
+      too slow. A request that announces a body larger than its limit is refused
+      before anything reaches the app. Once the response has started it can only
+      be cut off, and the connection is closed.
     - Since a request body streams through, each side can hold up the other: a
       slow client slows the send to the app, and an app slow to take the body
       slows the client's send. So while a request body is still on its way, a
@@ -450,10 +451,11 @@ The settings, by group:
       waiting for the app to take what it had.
     - Go's HTTP server, on which `smallwebwaf` is built, reads a request's line
       and headers before `smallwebwaf` sees the request. A client that takes
-      longer than `SWWAF_CLIENT_REQUEST_TIMEOUT` to send them gets no answer:
-      the server closes its connection. Headers over
-      `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` are answered `431` by the server
-      itself. Neither request gets a line in the request log.
+      longer than `SWWAF_CLIENT_REQUEST_TIMEOUT` to send them gets either no
+      answer or an error answer from the server, mostly `400 Bad Request`;
+      either way the server closes its connection and nothing reaches the app.
+      Headers over `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES` are answered `431` by
+      the server itself. Neither request gets a line in the request log.
     - A WebSocket connection leaves these limits behind once it is upgraded: it
       stays open until either side closes it.
 - Lookup of AS number and country (R7). On by default through GeoJS, which needs