Part of #165, where smallwebwaf rproxy, in front of each app, asks smallwebwaf servewaf whether to pass each request.
Today the Core Rule Set reads a request body only while SWWAF_WAF_BODY_LIMIT is set, which it is not by default, and rule files never see bodies. So at the defaults servewaf needs only the request line and headers.
Does rproxy send servewaf any part of the request body?
No (recommended). rproxy asks servewaf before reading the body, sending the method, path, query and headers. Then it streams the body straight to the app and holds none of it. SWWAF_WAF_BODY_LIMIT goes, so the Core Rule Set never refuses an attack carried in a body, as at today's default. The rule files, the limits and the bans still apply to the client that sends one.
Yes. rproxy holds the first part of each body in memory, up to a size given by a new rproxy setting, sends it with the request, and passes it on to the app after the answer. Every request in progress can then hold that much memory in rproxy, and the question to servewaf waits until the visitor has sent that part.
Recommendation: no.
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 the Core Rule Set reads a request body only while `SWWAF_WAF_BODY_LIMIT` is set, which it is not by default, and rule files never see bodies. So at the defaults `servewaf` needs only the request line and headers.
Does `rproxy` send `servewaf` any part of the request body?
- **No** (recommended). `rproxy` asks `servewaf` before reading the body, sending the method, path, query and headers. Then it streams the body straight to the app and holds none of it. `SWWAF_WAF_BODY_LIMIT` goes, so the Core Rule Set never refuses an attack carried in a body, as at today's default. The rule files, the limits and the bans still apply to the client that sends one.
- **Yes**. `rproxy` holds the first part of each body in memory, up to a size given by a new `rproxy` setting, sends it with the request, and passes it on to the app after the answer. Every request in progress can then hold that much memory in `rproxy`, and the question to `servewaf` waits until the visitor has sent that part.
Recommendation: no.
Model: opus-5-5
sneak
was assigned by clawbot2026-11-02 00:12:10 +01:00
I think that the first 64k of request bodies should go to the waf.
I envision a live request viewer functionality backend in the waf that allows for an admin to review inbound traffic and dispositions, inspect client metadata and counts, and optionally add netblock-level or AS-level or country-level bans or throttles.
Remember we are for the smallweb, we’re not trying to handle thousands of rps.
I also think requests should receive tags, based on ip info and scan results. things like torexit,asn=12345,vpn,vpn=mullvad,country=US,highrisk,exploitsignature
etc. Then users can configure throttling or blocking on a per-tag basis.
I think that the first 64k of request bodies should go to the waf.
I envision a live request viewer functionality backend in the waf that allows for an admin to review inbound traffic and dispositions, inspect client metadata and counts, and optionally add netblock-level or AS-level or country-level bans or throttles.
Remember we are for the smallweb, we’re not trying to handle thousands of rps.
I also think requests should receive tags, based on ip info and scan results. things like torexit,asn=12345,vpn,vpn=mullvad,country=US,highrisk,exploitsignature
etc. Then users can configure throttling or blocking on a per-tag basis.
The first 64 KiB of each request body goes to servewaf.
servewaf gets a live request viewer for the admin: inbound traffic with each request's disposition, client metadata and counts, and a way to add bans or throttles for a netblock, an AS or a country from there.
Each request gets tags from its IP information and scan results, for example torexit, asn=12345, vpn, vpn=mullvad, country=US, highrisk, exploitsignature; users configure throttling or blocking per tag.
The scale is the small web, not thousands of requests a second.
smallwebwaf is paused by sneak's order of 3 November (sneak/project-management#45); this goes into the design on #165 when it resumes, with each new piece (the viewer, the tags) filed as its own issue then.
Model: opus-5-5
Recorded (sneak, 4 November):
- The first 64 KiB of each request body goes to servewaf.
- servewaf gets a live request viewer for the admin: inbound traffic with each request's disposition, client metadata and counts, and a way to add bans or throttles for a netblock, an AS or a country from there.
- Each request gets tags from its IP information and scan results, for example `torexit`, `asn=12345`, `vpn`, `vpn=mullvad`, `country=US`, `highrisk`, `exploitsignature`; users configure throttling or blocking per tag.
- The scale is the small web, not thousands of requests a second.
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, with each new piece (the viewer, the tags) filed as its own issue then.
Model: opus-5-5
sneak
was unassigned by clawbot2026-11-04 13:36:51 +01:00
clawbot
self-assigned this 2026-11-04 13:36:51 +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 the Core Rule Set reads a request body only while
SWWAF_WAF_BODY_LIMITis set, which it is not by default, and rule files never see bodies. So at the defaultsservewafneeds only the request line and headers.Does
rproxysendservewafany part of the request body?rproxyasksservewafbefore reading the body, sending the method, path, query and headers. Then it streams the body straight to the app and holds none of it.SWWAF_WAF_BODY_LIMITgoes, so the Core Rule Set never refuses an attack carried in a body, as at today's default. The rule files, the limits and the bans still apply to the client that sends one.rproxyholds the first part of each body in memory, up to a size given by a newrproxysetting, sends it with the request, and passes it on to the app after the answer. Every request in progress can then hold that much memory inrproxy, and the question toservewafwaits until the visitor has sent that part.Recommendation: no.
Model: opus-5-5
I think that the first 64k of request bodies should go to the waf.
I envision a live request viewer functionality backend in the waf that allows for an admin to review inbound traffic and dispositions, inspect client metadata and counts, and optionally add netblock-level or AS-level or country-level bans or throttles.
Remember we are for the smallweb, we’re not trying to handle thousands of rps.
I also think requests should receive tags, based on ip info and scan results. things like torexit,asn=12345,vpn,vpn=mullvad,country=US,highrisk,exploitsignature
etc. Then users can configure throttling or blocking on a per-tag basis.
Recorded (sneak, 4 November):
torexit,asn=12345,vpn,vpn=mullvad,country=US,highrisk,exploitsignature; users configure throttling or blocking per tag.smallwebwaf is paused by sneak's order of 3 November (sneak/project-management#45); this goes into the design on #165 when it resumes, with each new piece (the viewer, the tags) filed as its own issue then.
Model: opus-5-5