smallwebwaf

13 Commits 3 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
sneak	23df4310f8	Explain when TestRequestTimeouts rightly gets 504 for a stopped client (closes #49 ) check / check (push) Successful in 2m15s Details 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	2026-10-04 02:55:18 +00:00
clawbot	f51459fbfe	Per-client request rate limits over a minute, an hour and a day (closes #43 ) check / check (push) Successful in 2m50s Details Each client, one IPv4 address or one IPv6 /64, is counted in two buckets per window, the earlier weighted by how much of it the window covers; at most 20,000 clients are kept, least recently seen dropped first. A request over SWWAF_RATE_LIMIT_PER_MINUTE, _HOUR or _DAY (1000, 10000, 50000, or off) gets 429 before reaching the app. Refused requests count, 413s included. A clock set back over a second behind a bucket's start restarts that window. The log line gains limit_hit and the action rate_limited. Deviation from SPEC.md, per the issue: the 20,000 bound and /64 are fixed. Judgement call: golang-lru/v2 holds the table; httprate does not count refused requests. Deviation: go.mod and go.sum hand-written; no make target tidies them. Model: opus-5-5	2026-10-04 04:24:34 +02:00
clawbot	d76715b0df	Pass-through proxy with timeouts, size limits and a request log (closes #13 ) check / check (push) Successful in 1m29s Details 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	2026-10-03 17:24:34 +02:00

Author

SHA1

Message

Date

sneak

23df4310f8

Explain when TestRequestTimeouts rightly gets 504 for a stopped client (closes #49 )

check / check (push) Successful in 2m15s

Details

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

2026-10-04 02:55:18 +00:00

clawbot

f51459fbfe

Per-client request rate limits over a minute, an hour and a day (closes #43 )

check / check (push) Successful in 2m50s

Details

Each client, one IPv4 address or one IPv6 /64, is counted in two buckets
per window, the earlier weighted by how much of it the window covers; at
most 20,000 clients are kept, least recently seen dropped first. A
request over SWWAF_RATE_LIMIT_PER_MINUTE, _HOUR or _DAY (1000, 10000,
50000, or off) gets 429 before reaching the app. Refused requests count,
413s included. A clock set back over a second behind a bucket's start
restarts that window. The log line gains limit_hit and the action
rate_limited.

Deviation from SPEC.md, per the issue: the 20,000 bound and /64 are fixed.
Judgement call: golang-lru/v2 holds the table; httprate does not count refused requests.
Deviation: go.mod and go.sum hand-written; no make target tidies them.

Model: opus-5-5

2026-10-04 04:24:34 +02:00

clawbot

d76715b0df

Pass-through proxy with timeouts, size limits and a request log (closes #13 )

check / check (push) Successful in 1m29s

Details

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

2026-10-03 17:24:34 +02:00