The case where the client stops sending halfway answers 504 only if,
when the request timeout runs out, smallwebwaf has not yet connected to
the app and passed on the first bytes: until then it is waiting on the
app, and SPEC.md asks for 504. That normally takes a few milliseconds of
the 300 ms timeout, so the failure needs the test process to be held up
for about 300 ms at the start of the request; a pause injected there
reproduces it exactly. The code is right, and the test could only gain
margin from a longer timeout, which the issue rules out. The comment
records this for the next reader.
Judgement call: no change to the code or to what the test checks.
Model: opus-5-5
Milestone 1, the repo's first code. smallwebwaf passes each request to the app and the answer back unchanged, streaming bodies and WebSocket upgrades, within four timeouts (client and app, request and response) and two size limits, and writes one JSON line per request to stdout. Every setting has an SWWAF_ name and a default, and an invalid value stops the start. The repo gets the standard layout: script/ entrypoints, make targets that call them, a Dockerfile that runs the checks, and the Gitea workflow.
Disclosure: SPEC.md changed. Go's server reads the request line and headers before smallwebwaf sees the request, so slow headers are closed without an answer, and neither slow nor oversized headers get a log line.
Disclosure: standard library only.
Model: opus-5-5
sneak
clawbot