Part of #165. The third of three units for the split, after servewaf (#170) and rproxy (#171). sneak ruled that the pair replaces today's one-process smallwebwaf (#166). This unit closes #165.
What to build
smallwebwaf with no command no longer runs a proxy: it prints the commands (rproxy, servewaf, healthcheck) and exits with status 2.
The one-process code goes: the passing-on code left in internal/proxy, now in internal/rproxy, and every path that only the one-process mode used.
The SWWAF_ settings that SWRP_ settings replaced go: SWWAF_UPSTREAM_URL, SWWAF_TRUSTED_PROXIES, SWWAF_REQUEST_MAX_BYTES, SWWAF_RESPONSE_MAX_BYTES, the five timeouts and SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES. SWWAF_WAF_BODY_LIMIT takes at most 64K, since servewaf never gets more of a body; it stays off by default.
The image runs smallwebwaf rproxy under runit by default, so that an app's image built FROM it has rproxy beside the app, as today. The same image runs servewaf in a container of its own, with the state volume; use the plainest way to choose and say it in the README. The state directory's change of owner happens only for servewaf. smallwebwaf healthcheck checks rproxy and the app in rproxy's container, and servewaf in servewaf's.
deploy/example-app and script/example-app move to the pair: the app with rproxy in its container, servewaf in another. The check adds: servewaf stopped, the app still answers through rproxy; started again, bans apply again.
script/run runs servewaf and rproxy on the host. script/gitea-requests runs gitea behind the pair.
Documents
README.md, SPEC.md and docs/ describe the new arrangement and nothing of the old: the usual setup of three containers (the app, rproxy and servewaf), the inherited setup with rproxy in the app's container, one servewaf for many sites sharing one table of clients and bans (#168), what happens when servewaf is down, slow or overloaded, and the settings of each. "Planned, not built" in SPEC.md drops sharing bans between apps where one servewaf now does it. Write each changed section fresh, plainly, for a newcomer; the old text is only reference.
Not in this unit
Renaming internal/proxy, whose name stops fitting once it passes nothing on, is #173.
Model: opus-5-5
Part of https://git.eeqj.de/sneak/smallwebwaf/issues/165. The third of three units for the split, after `servewaf` (https://git.eeqj.de/sneak/smallwebwaf/issues/170) and `rproxy` (https://git.eeqj.de/sneak/smallwebwaf/issues/171). sneak ruled that the pair replaces today's one-process `smallwebwaf` (https://git.eeqj.de/sneak/smallwebwaf/issues/166). This unit closes https://git.eeqj.de/sneak/smallwebwaf/issues/165.
## What to build
- `smallwebwaf` with no command no longer runs a proxy: it prints the commands (`rproxy`, `servewaf`, `healthcheck`) and exits with status 2.
- The one-process code goes: the passing-on code left in `internal/proxy`, now in `internal/rproxy`, and every path that only the one-process mode used.
- The `SWWAF_` settings that `SWRP_` settings replaced go: `SWWAF_UPSTREAM_URL`, `SWWAF_TRUSTED_PROXIES`, `SWWAF_REQUEST_MAX_BYTES`, `SWWAF_RESPONSE_MAX_BYTES`, the five timeouts and `SWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES`. `SWWAF_WAF_BODY_LIMIT` takes at most `64K`, since servewaf never gets more of a body; it stays off by default.
- The image runs `smallwebwaf rproxy` under runit by default, so that an app's image built `FROM` it has rproxy beside the app, as today. The same image runs `servewaf` in a container of its own, with the state volume; use the plainest way to choose and say it in the README. The state directory's change of owner happens only for servewaf. `smallwebwaf healthcheck` checks rproxy and the app in rproxy's container, and servewaf in servewaf's.
- `deploy/example-app` and `script/example-app` move to the pair: the app with rproxy in its container, servewaf in another. The check adds: servewaf stopped, the app still answers through rproxy; started again, bans apply again.
- `script/run` runs servewaf and rproxy on the host. `script/gitea-requests` runs gitea behind the pair.
## Documents
`README.md`, `SPEC.md` and `docs/` describe the new arrangement and nothing of the old: the usual setup of three containers (the app, rproxy and servewaf), the inherited setup with rproxy in the app's container, one servewaf for many sites sharing one table of clients and bans (https://git.eeqj.de/sneak/smallwebwaf/issues/168), what happens when servewaf is down, slow or overloaded, and the settings of each. "Planned, not built" in `SPEC.md` drops sharing bans between apps where one servewaf now does it. Write each changed section fresh, plainly, for a newcomer; the old text is only reference.
## Not in this unit
Renaming `internal/proxy`, whose name stops fitting once it passes nothing on, is https://git.eeqj.de/sneak/smallwebwaf/issues/173.
Model: opus-5-5
clawbot
self-assigned this 2026-11-04 20:09:56 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #165. The third of three units for the split, after
servewaf(#170) andrproxy(#171). sneak ruled that the pair replaces today's one-processsmallwebwaf(#166). This unit closes #165.What to build
smallwebwafwith no command no longer runs a proxy: it prints the commands (rproxy,servewaf,healthcheck) and exits with status 2.internal/proxy, now ininternal/rproxy, and every path that only the one-process mode used.SWWAF_settings thatSWRP_settings replaced go:SWWAF_UPSTREAM_URL,SWWAF_TRUSTED_PROXIES,SWWAF_REQUEST_MAX_BYTES,SWWAF_RESPONSE_MAX_BYTES, the five timeouts andSWWAF_CLIENT_REQUEST_HEADER_MAX_BYTES.SWWAF_WAF_BODY_LIMITtakes at most64K, since servewaf never gets more of a body; it stays off by default.smallwebwaf rproxyunder runit by default, so that an app's image builtFROMit has rproxy beside the app, as today. The same image runsservewafin a container of its own, with the state volume; use the plainest way to choose and say it in the README. The state directory's change of owner happens only for servewaf.smallwebwaf healthcheckchecks rproxy and the app in rproxy's container, and servewaf in servewaf's.deploy/example-appandscript/example-appmove to the pair: the app with rproxy in its container, servewaf in another. The check adds: servewaf stopped, the app still answers through rproxy; started again, bans apply again.script/runruns servewaf and rproxy on the host.script/gitea-requestsruns gitea behind the pair.Documents
README.md,SPEC.mdanddocs/describe the new arrangement and nothing of the old: the usual setup of three containers (the app, rproxy and servewaf), the inherited setup with rproxy in the app's container, one servewaf for many sites sharing one table of clients and bans (#168), what happens when servewaf is down, slow or overloaded, and the settings of each. "Planned, not built" inSPEC.mddrops sharing bans between apps where one servewaf now does it. Write each changed section fresh, plainly, for a newcomer; the old text is only reference.Not in this unit
Renaming
internal/proxy, whose name stops fitting once it passes nothing on, is #173.Model: opus-5-5
clawbot referenced this issue2026-11-04 20:41:25 +01:00