When servewaf is answering requests, it must always answer the rproxy faster than the rproxy's default timeout that fails open. That means that it needs strict timeouts on all of its own internal decision-inputs, and needs to deny very quickly if it's a rate limit or ip/country ban or bogon header. It's ok to set some slightly aggressive header limits that won't be hit in real practice, such a Cookie header should be an instant-fail due to bogosity.
Found in review of rproxy (#181 (comment), finding 1): a Cookie header of a; repeated 16,000 times fits the 32 KiB header limit and keeps the Core Rule Set busy for over a second, so two such requests at once on one core pass SWRP_TIMEOUT_MS and the default passes them to the app unchecked. Today servewaf can also wait up to SWWAF_LOOKUP_TIMEOUT (1 s) for GeoJS and SWWAF_REPUTATION_TIMEOUT (2 s) for each DNS blocklist and AbuseIPDB, together more than rproxy's 2 s.
Built now, beside the rework of #181 and before #172.
Definition of done
At the defaults, servewaf answers every question well within SWRP_TIMEOUT_MS's default of 2 s, whatever the request and whatever its outside sources do: the waits on GeoJS, the DNS blocklists, AbuseIPDB and any other outside source servewaf waits on while deciding together stay under 1 s, and a source that runs out of time counts as no answer, as today.
A request refused by the static lists, a ban, a country list or the rate limits is answered without waiting on any outside source that its refusal does not need.
Before the Core Rule Set runs, servewaf refuses a request with bogus headers, at limits real clients never reach: more than 50 cookies, or more than 100 header fields. Each limit is fixed, with no setting, and is listed with its refusal in SPEC.md.
Tests: the 16,000-cookie request refused well within the time limit; a request over each limit refused; a slow outside source not holding up a refused request; servewaf answering within the time limit while every outside source hangs.
SPEC.md and docs/settings.md say all this; the sentence on a slow servewaf that #181 adds follows.
Model: opus-5-5
sneak, 5 November, on https://git.eeqj.de/sneak/smallwebwaf/pulls/181#issuecomment-168570, verbatim:
> When servewaf is answering requests, it must always answer the rproxy faster than the rproxy's default timeout that fails open. That means that it needs strict timeouts on all of its own internal decision-inputs, and needs to deny very quickly if it's a rate limit or ip/country ban or bogon header. It's ok to set some slightly aggressive header limits that won't be hit in real practice, such a Cookie header should be an instant-fail due to bogosity.
Found in review of rproxy (https://git.eeqj.de/sneak/smallwebwaf/pulls/181#issuecomment-168511, finding 1): a `Cookie` header of `a;` repeated 16,000 times fits the 32 KiB header limit and keeps the Core Rule Set busy for over a second, so two such requests at once on one core pass `SWRP_TIMEOUT_MS` and the default passes them to the app unchecked. Today servewaf can also wait up to `SWWAF_LOOKUP_TIMEOUT` (1 s) for GeoJS and `SWWAF_REPUTATION_TIMEOUT` (2 s) for each DNS blocklist and AbuseIPDB, together more than rproxy's 2 s.
Built now, beside the rework of https://git.eeqj.de/sneak/smallwebwaf/pulls/181 and before https://git.eeqj.de/sneak/smallwebwaf/issues/172.
## Definition of done
- At the defaults, servewaf answers every question well within `SWRP_TIMEOUT_MS`'s default of 2 s, whatever the request and whatever its outside sources do: the waits on GeoJS, the DNS blocklists, AbuseIPDB and any other outside source servewaf waits on while deciding together stay under 1 s, and a source that runs out of time counts as no answer, as today.
- A request refused by the static lists, a ban, a country list or the rate limits is answered without waiting on any outside source that its refusal does not need.
- Before the Core Rule Set runs, servewaf refuses a request with bogus headers, at limits real clients never reach: more than 50 cookies, or more than 100 header fields. Each limit is fixed, with no setting, and is listed with its refusal in `SPEC.md`.
- Tests: the 16,000-cookie request refused well within the time limit; a request over each limit refused; a slow outside source not holding up a refused request; servewaf answering within the time limit while every outside source hangs.
- `SPEC.md` and `docs/settings.md` say all this; the sentence on a slow servewaf that https://git.eeqj.de/sneak/smallwebwaf/pulls/181 adds follows.
Model: opus-5-5
clawbot
self-assigned this 2026-11-05 02:49:15 +01:00
clawbot
changed title from A visitor can keep servewaf busy past rproxy's time limit, so the default passes its request to servewaf always answers rproxy well within its time limit2026-11-05 03:39:07 +01:00
Built in #183, whose body is the record. One correction to this issue: no request waits on the DNS blocklists or AbuseIPDB, which run in the background, so GeoJS is the only wait and SWWAF_REPUTATION_TIMEOUT stays 2s.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/smallwebwaf/pulls/183, whose body is the record. One correction to this issue: no request waits on the DNS blocklists or AbuseIPDB, which run in the background, so GeoJS is the only wait and `SWWAF_REPUTATION_TIMEOUT` stays `2s`.
Model: opus-5-5
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.
sneak, 5 November, on #181 (comment), verbatim:
Found in review of rproxy (#181 (comment), finding 1): a
Cookieheader ofa;repeated 16,000 times fits the 32 KiB header limit and keeps the Core Rule Set busy for over a second, so two such requests at once on one core passSWRP_TIMEOUT_MSand the default passes them to the app unchecked. Today servewaf can also wait up toSWWAF_LOOKUP_TIMEOUT(1 s) for GeoJS andSWWAF_REPUTATION_TIMEOUT(2 s) for each DNS blocklist and AbuseIPDB, together more than rproxy's 2 s.Built now, beside the rework of #181 and before #172.
Definition of done
SWRP_TIMEOUT_MS's default of 2 s, whatever the request and whatever its outside sources do: the waits on GeoJS, the DNS blocklists, AbuseIPDB and any other outside source servewaf waits on while deciding together stay under 1 s, and a source that runs out of time counts as no answer, as today.SPEC.md.SPEC.mdanddocs/settings.mdsay all this; the sentence on a slow servewaf that #181 adds follows.Model: opus-5-5
A visitor can keep servewaf busy past rproxy's time limit, so the default passes its requestto servewaf always answers rproxy well within its time limitBuilt in #183, whose body is the record. One correction to this issue: no request waits on the DNS blocklists or AbuseIPDB, which run in the background, so GeoJS is the only wait and
SWWAF_REPUTATION_TIMEOUTstays2s.Model: opus-5-5