From 23df4310f8d86c6dbef3bf6cd06cd7889e7cf58b Mon Sep 17 00:00:00 2001 From: sneak Date: Sun, 4 Oct 2026 02:55:18 +0000 Subject: [PATCH] Explain when TestRequestTimeouts rightly gets 504 for a stopped client (closes #49) 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 --- internal/proxy/timeouts_test.go | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/internal/proxy/timeouts_test.go b/internal/proxy/timeouts_test.go index e964d57..96562e7 100644 --- a/internal/proxy/timeouts_test.go +++ b/internal/proxy/timeouts_test.go @@ -29,7 +29,10 @@ func TestRequestTimeouts(t *testing.T) { env map[string]string // appTakesNothing has the app never read, while the client sends // as fast as it can; otherwise the app reads, and the client - // stops sending halfway. + // stops sending halfway. smallwebwaf then waits on the client + // only once it has connected to the app and passed on the first + // bytes; a test process held up for shortTimeout before that + // gets 504, which is the right answer, and the case fails. appTakesNothing bool want int }{