Part of #165, where smallwebwaf rproxy, in front of each app, asks smallwebwaf servewaf whether to pass each request.
Today smallwebwaf is one process in the app's container that both checks each request and passes it to the app. Does that stay as a third way to run it, or do rproxy and servewaf replace it?
Replace (recommended). One way to run it: every app's container runs rproxy in front of the app, and servewaf runs from the same image in a container of its own, with the state volume. The size and time limits become rproxy's SWRP_ settings, and their SWWAF_ counterparts go. The cost: a single app needs a second container, each request makes one more call over the host's network, and the image, README.md and SPEC.md change around the new arrangement.
Keep. Today's arrangement stays as it is, beside the new pair. Nothing changes for a single app, but passing requests to the app, its limits, and the documents exist twice, once for each arrangement.
Recommendation: replace, so that there is one arrangement and one set of limits.
Model: opus-5-5
Part of https://git.eeqj.de/sneak/smallwebwaf/issues/165, where `smallwebwaf rproxy`, in front of each app, asks `smallwebwaf servewaf` whether to pass each request.
Today `smallwebwaf` is one process in the app's container that both checks each request and passes it to the app. Does that stay as a third way to run it, or do `rproxy` and `servewaf` replace it?
- **Replace** (recommended). One way to run it: every app's container runs `rproxy` in front of the app, and `servewaf` runs from the same image in a container of its own, with the state volume. The size and time limits become `rproxy`'s `SWRP_` settings, and their `SWWAF_` counterparts go. The cost: a single app needs a second container, each request makes one more call over the host's network, and the image, `README.md` and `SPEC.md` change around the new arrangement.
- **Keep**. Today's arrangement stays as it is, beside the new pair. Nothing changes for a single app, but passing requests to the app, its limits, and the documents exist twice, once for each arrangement.
Recommendation: replace, so that there is one arrangement and one set of limits.
Model: opus-5-5
sneak
was assigned by clawbot2026-11-02 00:12:10 +01:00
Replace. Also while we will use the inherited container setup, most people will run the rproxy in a separate container from the app, so in the usual case it will be 3 containers.
Replace. Also while we will use the inherited container setup, most people will run the rproxy in a separate container from the app, so in the usual case it will be 3 containers.
Recorded (sneak, 4 November): rproxy and servewaf replace today's one-process smallwebwaf. Most people will run rproxy in a container of its own, separate from the app, so the usual setup is three containers: the app, rproxy and servewaf; the inherited setup with rproxy in the app's container stays possible.
smallwebwaf is paused by sneak's order of 3 November (sneak/project-management#45); this goes into the design on #165 when it resumes.
Model: opus-5-5
Recorded (sneak, 4 November): rproxy and servewaf replace today's one-process smallwebwaf. Most people will run rproxy in a container of its own, separate from the app, so the usual setup is three containers: the app, rproxy and servewaf; the inherited setup with rproxy in the app's container stays possible.
smallwebwaf is paused by sneak's order of 3 November (https://git.eeqj.de/sneak/project-management/issues/45); this goes into the design on https://git.eeqj.de/sneak/smallwebwaf/issues/165 when it resumes.
Model: opus-5-5
sneak
was unassigned by clawbot2026-11-04 13:21:37 +01:00
clawbot
self-assigned this 2026-11-04 13:21:37 +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, where
smallwebwaf rproxy, in front of each app, askssmallwebwaf servewafwhether to pass each request.Today
smallwebwafis one process in the app's container that both checks each request and passes it to the app. Does that stay as a third way to run it, or dorproxyandservewafreplace it?rproxyin front of the app, andservewafruns from the same image in a container of its own, with the state volume. The size and time limits becomerproxy'sSWRP_settings, and theirSWWAF_counterparts go. The cost: a single app needs a second container, each request makes one more call over the host's network, and the image,README.mdandSPEC.mdchange around the new arrangement.Recommendation: replace, so that there is one arrangement and one set of limits.
Model: opus-5-5
Replace. Also while we will use the inherited container setup, most people will run the rproxy in a separate container from the app, so in the usual case it will be 3 containers.
Recorded (sneak, 4 November): rproxy and servewaf replace today's one-process smallwebwaf. Most people will run rproxy in a container of its own, separate from the app, so the usual setup is three containers: the app, rproxy and servewaf; the inherited setup with rproxy in the app's container stays possible.
smallwebwaf is paused by sneak's order of 3 November (sneak/project-management#45); this goes into the design on #165 when it resumes.
Model: opus-5-5