why is max bans configurable? it needs to be bounded because we can’t have infinite memory use but it can be defined in code at some high value like 100000 and does not need to be tunable in any normal use case.
audit all settings and propose any here that can be defined in code and removed from settings.
why is max bans configurable? it needs to be bounded because we can’t have infinite memory use but it can be defined in code at some high value like 100000 and does not need to be tunable in any normal use case.
audit all settings and propose any here that can be defined in code and removed from settings.
Picked up for smallwebwaf's manager. The audit lists every setting that can become a constant in the code, each with the value it would take and why nobody needs to tune it, such as the ban count at 100,000. The list goes here for your yes before anything is removed.
Model: opus-5-5
Picked up for smallwebwaf's manager. The audit lists every setting that can become a constant in the code, each with the value it would take and why nobody needs to tune it, such as the ban count at 100,000. The list goes here for your yes before anything is removed.
Model: opus-5-5
clawbot
self-assigned this 2026-11-06 19:22:08 +01:00
For the genius-bar: audit every SWRP_ and SWWAF_ setting on current next and post, as one comment here, the ones that can become a constant in the code, for sneak's yes. Write no code.
The test, from sneak's words above: a setting stays only if an operator needs it in normal use: it says what to protect, from whom, or where things are (addresses, URLs, keys, lists, modes, the limits a site is sized by). A bound that exists only to cap memory or work, a cache time, an internal timing or a retry count fails, and becomes a constant at a value high enough that nobody meets it, such as the ban count at 100,000.
For each setting that fails: its name, where it is defined, today's default, the constant it would become, and one line on why nobody needs to tune it. Leave settings that pass unlisted.
Include the settings planned but not yet built: #194 (comment) (with its correction below it) and #175 (comment).
End with one question for sneak: remove the listed settings? Recommended answer, with the options as bullets.
Model: opus-5-5
For the genius-bar: audit every `SWRP_` and `SWWAF_` setting on current `next` and post, as one comment here, the ones that can become a constant in the code, for sneak's yes. Write no code.
- **The test, from sneak's words above:** a setting stays only if an operator needs it in normal use: it says what to protect, from whom, or where things are (addresses, URLs, keys, lists, modes, the limits a site is sized by). A bound that exists only to cap memory or work, a cache time, an internal timing or a retry count fails, and becomes a constant at a value high enough that nobody meets it, such as the ban count at 100,000.
- **For each setting that fails:** its name, where it is defined, today's default, the constant it would become, and one line on why nobody needs to tune it. Leave settings that pass unlisted.
- Include the settings planned but not yet built: https://git.eeqj.de/sneak/smallwebwaf/issues/194#issuecomment-169736 (with its correction below it) and https://git.eeqj.de/sneak/smallwebwaf/issues/175#issuecomment-169989.
- End with one question for sneak: remove the listed settings? Recommended answer, with the options as bullets.
Model: opus-5-5
Why max bans is a setting: nothing needs it to be. It only bounds memory, and no document gives an operator a reason to change it. Eleven more settings are like it.
Proposal: twelve settings become constants in the code.
The test: a setting stays only if an operator needs it in normal use. A bound that only caps memory or work, a cache time or an internal timing fails.
Read from next at a63b7e4. Every line number is in internal/config/config.go.
None of the planned settings is on the list: those of the many-requests byte limit (#194 (comment)) and of request tags (#175 (comment)).
Fail the test clearly (confidence high, except where a line says otherwise)
SWWAF_MAX_BANS (line 508, default 5000) becomes 100,000. It only bounds memory. See the catch below.
SWWAF_MAX_TRACKED_CLIENTS (line 467, default 20000) becomes 100,000. It only bounds memory. The GeoJS answers, one per client, are already fixed at 100,000. See the catch below.
SWWAF_LOG_REMOTE_BUFFER (line 532, default 10000) becomes 10,000 lines. It only bounds memory while the syslog server is slow or down. Stdout carries every line whatever happens.
SWWAF_METRICS_TOP_N (line 518, default 50) becomes 50. It only bounds the number of metric series. The other AS numbers and countries are summed as other, and the request log names each one.
SWWAF_STATE_WRITE_DELAY (line 511, default 10s) becomes 10 seconds. It is an internal timing: a burst of ban changes becomes one write of bans.json. Only a hard kill loses those 10 seconds.
SWWAF_STATE_COUNTER_INTERVAL (line 512, default 15m) becomes 15 minutes. It is an internal timing: how often every state file is written. An orderly stop writes them all, so only a hard kill loses up to 15 minutes of counters.
SWWAF_REPUTATION_CACHE_TTL (line 499, default 24h) becomes 24 hours. It is a cache time: how long a DNS blocklist verdict or an AbuseIPDB score is used.
SWWAF_REPUTATION_TIMEOUT (line 500, default 2s) becomes 2 seconds. It is an internal timing: how long one DNS blocklist query or AbuseIPDB check may take. Those are made in the background, so no request waits for them.
SWWAF_LOOKUP_TIMEOUT (line 481, default 800ms) becomes 800 milliseconds. Confidence medium. It is an internal timing: how long a new client's first request waits for GeoJS. The catch: it must stay under SWRP_TIMEOUT_MS (default 2000), which stays a setting. An operator who lowers that one below about a second could no longer lower this one to match, and requests waiting for GeoJS would get SWRP_DEFAULT_DISPOSITION.
The catch on the two table sizes
Nothing leaves either table before it is full: ended bans and idle clients are kept. So a busy site fills both in time, whatever the figure.
Every state file is written whole every 15 minutes, and bans.json again 10 seconds after a ban changes.
At 100,000 each, a full bans.json is about 120 MiB and a full clients.json about 100 MiB. Today they are 6 MiB and 20 MiB. Disk writes for the two files rise from about 2.5 GiB a day to about 20 GiB.
Today's figures as the constants (5,000 and 20,000) avoid that. The cost of 20,000 clients: on a day with more clients than that, the ones seen longest ago are dropped with their counters, so a slow scraper's daily count can start afresh.
Fail less clearly (confidence medium)
SWWAF_ANOMALY_NET_V4_PREFIX (line 548, default 24) and SWWAF_ANOMALY_NET_V6_PREFIX (line 549, default 48) become /24 and /48. They size the netblock around a client for the anomaly alerts, which block nothing. A /24 and a /48 are the smallest netblocks routed on the internet. A netblock of any other size can be named in SWWAF_WATCH_NETS.
SWWAF_LOG_LEVEL (line 515, default info) becomes info. No message is logged at debug. warn and error only hide servewaf's own messages, such as the line of settings at start, never a request line. rproxy has no such setting and writes at info.
Judgement calls: left as settings
SWRP_TIMEOUT_MS: an internal timing by the test, but one of the settings you listed for rproxy yourself (#165 (comment)).
SWWAF_BLOCKLIST_REFRESH: a cache time by the test. It also decides how soon an edit to a list you host yourself reaches each servewaf, such as the file SWWAF_ASN_LIMIT_PERCENT_URL names. No one figure suits both that and a list such as Spamhaus DROP, whose terms forbid fetching more than once an hour and call once a day enough.
SWWAF_ABUSEIPDB_DAILY_BUDGET: sized by the operator's AbuseIPDB plan.
SWWAF_ALERT_COOLDOWN and SWWAF_ALERT_MAX_PER_HOUR: they fit the flow of alerts to where it goes, a phone or a log collector.
SWWAF_WAF_BODY_LIMIT: its size could be a constant, but the setting would stay as the switch for body inspection, so nothing would be removed.
Not checked
The file sizes are worked out from the per-entry sizes in docs/state-files.md. Nothing was measured, memory use included.
For the manager's plan, if approved
Each setting loses its environment variable, its parsing and its rows in README.md, docs/settings.md and SPEC.md. "Fixed limits" in docs/settings.md gains its figure. No old name is kept.
The packages keep taking these values as parameters, so tests can still pass small ones.
Larger tables make three statements false: the sizes in docs/state-files.md, and in SPEC.md that a state file is written in well under a second and that the volume holds a few tens of MiB.
Six of the names are on the rename list (#192 (comment)). A removed setting needs no rename.
The planned routewatch module (#204) caches its answers for a time. By this test that time is a constant, not a setting.
Question: remove these twelve settings, each becoming the constant shown above?
Example: today SWWAF_MAX_BANS=20000 in a compose file changes how many bans servewaf keeps. After removal that line does nothing, and every servewaf keeps up to 100,000.
All listed (recommended): both groups become constants.
Clear group only: the nine in the first group become constants. The anomaly netblock sizes and the log level stay settings.
None: every setting stays.
Putting one back later is its line in internal/config and its rows in the documents.
Model: fable-5-1
**Why max bans is a setting:** nothing needs it to be. It only bounds memory, and no document gives an operator a reason to change it. Eleven more settings are like it.
**Proposal:** twelve settings become constants in the code.
- The test: a setting stays only if an operator needs it in normal use. A bound that only caps memory or work, a cache time or an internal timing fails.
- Read from `next` at `a63b7e4`. Every line number is in `internal/config/config.go`.
- None of the planned settings is on the list: those of the many-requests byte limit (https://git.eeqj.de/sneak/smallwebwaf/issues/194#issuecomment-169736) and of request tags (https://git.eeqj.de/sneak/smallwebwaf/issues/175#issuecomment-169989).
**Fail the test clearly** (confidence high, except where a line says otherwise)
- `SWWAF_MAX_BANS` (line 508, default `5000`) becomes 100,000. It only bounds memory. See the catch below.
- `SWWAF_MAX_TRACKED_CLIENTS` (line 467, default `20000`) becomes 100,000. It only bounds memory. The GeoJS answers, one per client, are already fixed at 100,000. See the catch below.
- `SWWAF_LOG_REMOTE_BUFFER` (line 532, default `10000`) becomes 10,000 lines. It only bounds memory while the syslog server is slow or down. Stdout carries every line whatever happens.
- `SWWAF_METRICS_TOP_N` (line 518, default `50`) becomes 50. It only bounds the number of metric series. The other AS numbers and countries are summed as `other`, and the request log names each one.
- `SWWAF_STATE_WRITE_DELAY` (line 511, default `10s`) becomes 10 seconds. It is an internal timing: a burst of ban changes becomes one write of `bans.json`. Only a hard kill loses those 10 seconds.
- `SWWAF_STATE_COUNTER_INTERVAL` (line 512, default `15m`) becomes 15 minutes. It is an internal timing: how often every state file is written. An orderly stop writes them all, so only a hard kill loses up to 15 minutes of counters.
- `SWWAF_REPUTATION_CACHE_TTL` (line 499, default `24h`) becomes 24 hours. It is a cache time: how long a DNS blocklist verdict or an AbuseIPDB score is used.
- `SWWAF_REPUTATION_TIMEOUT` (line 500, default `2s`) becomes 2 seconds. It is an internal timing: how long one DNS blocklist query or AbuseIPDB check may take. Those are made in the background, so no request waits for them.
- `SWWAF_LOOKUP_TIMEOUT` (line 481, default `800ms`) becomes 800 milliseconds. Confidence medium. It is an internal timing: how long a new client's first request waits for GeoJS. The catch: it must stay under `SWRP_TIMEOUT_MS` (default `2000`), which stays a setting. An operator who lowers that one below about a second could no longer lower this one to match, and requests waiting for GeoJS would get `SWRP_DEFAULT_DISPOSITION`.
**The catch on the two table sizes**
- Nothing leaves either table before it is full: ended bans and idle clients are kept. So a busy site fills both in time, whatever the figure.
- Every state file is written whole every 15 minutes, and `bans.json` again 10 seconds after a ban changes.
- At 100,000 each, a full `bans.json` is about 120 MiB and a full `clients.json` about 100 MiB. Today they are 6 MiB and 20 MiB. Disk writes for the two files rise from about 2.5 GiB a day to about 20 GiB.
- Today's figures as the constants (5,000 and 20,000) avoid that. The cost of 20,000 clients: on a day with more clients than that, the ones seen longest ago are dropped with their counters, so a slow scraper's daily count can start afresh.
**Fail less clearly** (confidence medium)
- `SWWAF_ANOMALY_NET_V4_PREFIX` (line 548, default `24`) and `SWWAF_ANOMALY_NET_V6_PREFIX` (line 549, default `48`) become /24 and /48. They size the netblock around a client for the anomaly alerts, which block nothing. A /24 and a /48 are the smallest netblocks routed on the internet. A netblock of any other size can be named in `SWWAF_WATCH_NETS`.
- `SWWAF_LOG_LEVEL` (line 515, default `info`) becomes `info`. No message is logged at `debug`. `warn` and `error` only hide `servewaf`'s own messages, such as the line of settings at start, never a request line. `rproxy` has no such setting and writes at `info`.
**Judgement calls: left as settings**
- `SWRP_TIMEOUT_MS`: an internal timing by the test, but one of the settings you listed for `rproxy` yourself (https://git.eeqj.de/sneak/smallwebwaf/issues/165#issuecomment-160276).
- `SWWAF_BLOCKLIST_REFRESH`: a cache time by the test. It also decides how soon an edit to a list you host yourself reaches each `servewaf`, such as the file `SWWAF_ASN_LIMIT_PERCENT_URL` names. No one figure suits both that and a list such as Spamhaus DROP, whose terms forbid fetching more than once an hour and call once a day enough.
- `SWWAF_ABUSEIPDB_DAILY_BUDGET`: sized by the operator's AbuseIPDB plan.
- `SWWAF_ALERT_COOLDOWN` and `SWWAF_ALERT_MAX_PER_HOUR`: they fit the flow of alerts to where it goes, a phone or a log collector.
- `SWWAF_WAF_BODY_LIMIT`: its size could be a constant, but the setting would stay as the switch for body inspection, so nothing would be removed.
**Not checked**
- The file sizes are worked out from the per-entry sizes in `docs/state-files.md`. Nothing was measured, memory use included.
**For the manager's plan, if approved**
- Each setting loses its environment variable, its parsing and its rows in `README.md`, `docs/settings.md` and `SPEC.md`. "Fixed limits" in `docs/settings.md` gains its figure. No old name is kept.
- The packages keep taking these values as parameters, so tests can still pass small ones.
- Larger tables make three statements false: the sizes in `docs/state-files.md`, and in `SPEC.md` that a state file is written in well under a second and that the volume holds a few tens of MiB.
- Six of the names are on the rename list (https://git.eeqj.de/sneak/smallwebwaf/issues/192#issuecomment-169850). A removed setting needs no rename.
- The planned routewatch module (https://git.eeqj.de/sneak/smallwebwaf/issues/204) caches its answers for a time. By this test that time is a constant, not a setting.
**Question:** remove these twelve settings, each becoming the constant shown above?
Example: today `SWWAF_MAX_BANS=20000` in a compose file changes how many bans `servewaf` keeps. After removal that line does nothing, and every `servewaf` keeps up to 100,000.
- **All listed** (recommended): both groups become constants.
- **Clear group only**: the nine in the first group become constants. The anomaly netblock sizes and the log level stay settings.
- **None**: every setting stays.
Putting one back later is its line in `internal/config` and its rows in the documents.
Model: fable-5-1
The audit above is ready for sneak's yes. Its question is at the end: should these twelve settings be removed, each becoming the constant shown? It recommends all listed. One cost to weigh: at 100,000 bans and 100,000 clients, the two state files grow from 6 and 20 MiB to about 120 and 100 MiB, and disk writes from about 2.5 GiB a day to about 20 GiB.
Model: opus-5-5
The audit above is ready for sneak's yes. Its question is at the end: should these twelve settings be removed, each becoming the constant shown? It recommends all listed. One cost to weigh: at 100,000 bans and 100,000 clients, the two state files grow from 6 and 20 MiB to about 120 and 100 MiB, and disk writes from about 2.5 GiB a day to about 20 GiB.
Model: opus-5-5
clawbot
removed their assignment 2026-11-06 20:21:25 +01:00
sneak
was assigned by clawbot2026-11-06 20:21:25 +01:00
read and write all of the json files to disk as zstd compressed.
SWWAF_METRICS_TOP_N should be default to 100
SWWAF_REPUTATION_CACHE_TTL should default to 6h and should remain configurable and should be named SWWAF_IP_REPUTATION_CACHE_TTL - ambiguous and unclear names are VERY BAD and should be avoided EVERYWHERE ALWAYS.
SWWAF_REPUTATION_TIMEOUT (line 500, default 2s) becomes 2 seconds. It is an internal timing: how long one DNS blocklist query or AbuseIPDB check may take. Those are made in the background, so no request waits for them.
SWWAF_REPUTATION_TIMEOUT should be renamed - wtf is a reputation timeout? it should also be _MS for units. 2000 is an ok default but it should be configurable.
SWWAF_LOOKUP_TIMEOUT (line 481, default 800ms) becomes 800 milliseconds. Confidence medium. It is an internal timing: how long a new client's first request waits for GeoJS.
LOOKUP_TIMEOUT is ambiguous and must be renamed - it also needs _MS for units. what is it looking up? a user must be able to understand a setting in isolation without referring to the docs every time.
The catch: it must stay under SWRP_TIMEOUT_MS (default 2000), which stays a setting. An operator who lowers that one below about a second could no longer lower this one to match, and requests waiting for GeoJS would get SWRP_DEFAULT_DISPOSITION.
SWRP_TIMEOUT_MS is also totally ambiguous and must be renamed. i have no idea what it means and therefore a user doesn't know what it means. is it a request timeout? a decider timeout? a backend timeout? a reputation service timeout? stop wasting the user's time.
read and write all of the json files to disk as zstd compressed.
SWWAF_METRICS_TOP_N should be default to 100
SWWAF_REPUTATION_CACHE_TTL should default to 6h and should remain configurable and should be named SWWAF_IP_REPUTATION_CACHE_TTL - ambiguous and unclear names are VERY BAD and should be avoided EVERYWHERE ALWAYS.
SWWAF_REPUTATION_TIMEOUT (line 500, default 2s) becomes 2 seconds. It is an internal timing: how long one DNS blocklist query or AbuseIPDB check may take. Those are made in the background, so no request waits for them.
SWWAF_REPUTATION_TIMEOUT should be renamed - wtf is a reputation timeout? it should also be _MS for units. 2000 is an ok default but it should be configurable.
SWWAF_LOOKUP_TIMEOUT (line 481, default 800ms) becomes 800 milliseconds. Confidence medium. It is an internal timing: how long a new client's first request waits for GeoJS.
LOOKUP_TIMEOUT is ambiguous and must be renamed - it also needs _MS for units. what is it looking up? a user must be able to understand a setting in isolation without referring to the docs every time.
The catch: it must stay under SWRP_TIMEOUT_MS (default 2000), which stays a setting. An operator who lowers that one below about a second could no longer lower this one to match, and requests waiting for GeoJS would get SWRP_DEFAULT_DISPOSITION.
SWRP_TIMEOUT_MS is also totally ambiguous and must be renamed. i have no idea what it means and therefore a user doesn't know what it means. is it a request timeout? a decider timeout? a backend timeout? a reputation service timeout? stop wasting the user's time.
Recorded from sneak's answer above, for smallwebwaf's manager:
State files are written and read zstd-compressed. See #217, filed minutes later, which replaces them with SQLite; that question is put to him there.
SWWAF_METRICS_TOP_N stays a setting, default 100.
SWWAF_REPUTATION_CACHE_TTL stays a setting, default 6 hours, renamed SWWAF_IP_REPUTATION_CACHE_TTL.
SWWAF_REPUTATION_TIMEOUT stays a setting, default 2000. Its new name says what it times, the DNS blocklist and AbuseIPDB checks, and ends in _MS.
SWWAF_LOOKUP_TIMEOUT stays a setting. Its new name says what is looked up, the client address's location, and ends in _MS.
SWRP_TIMEOUT_MS is renamed to say which wait it limits: how long rproxy waits for servewaf's answer.
Every setting name must make sense on its own, without the docs. This goes into the naming audit (#192).
Still open, for sneak: the eight he did not mention. Do they become constants as proposed?
SWWAF_MAX_BANS and SWWAF_MAX_TRACKED_CLIENTS, at 100,000 each;
SWWAF_LOG_REMOTE_BUFFER;
SWWAF_STATE_WRITE_DELAY and SWWAF_STATE_COUNTER_INTERVAL;
the two anomaly netblock sizes and the log level.
Recommended: yes for the first five. The anomaly netblock sizes and the log level stay settings.
Model: opus-5-5
Recorded from sneak's answer above, for smallwebwaf's manager:
- **State files** are written and read zstd-compressed. See https://git.eeqj.de/sneak/smallwebwaf/issues/217, filed minutes later, which replaces them with SQLite; that question is put to him there.
- **`SWWAF_METRICS_TOP_N`** stays a setting, default 100.
- **`SWWAF_REPUTATION_CACHE_TTL`** stays a setting, default 6 hours, renamed `SWWAF_IP_REPUTATION_CACHE_TTL`.
- **`SWWAF_REPUTATION_TIMEOUT`** stays a setting, default 2000. Its new name says what it times, the DNS blocklist and AbuseIPDB checks, and ends in `_MS`.
- **`SWWAF_LOOKUP_TIMEOUT`** stays a setting. Its new name says what is looked up, the client address's location, and ends in `_MS`.
- **`SWRP_TIMEOUT_MS`** is renamed to say which wait it limits: how long `rproxy` waits for `servewaf`'s answer.
- **Every setting name** must make sense on its own, without the docs. This goes into the naming audit (https://git.eeqj.de/sneak/smallwebwaf/issues/192).
**Still open, for sneak:** the eight he did not mention. Do they become constants as proposed?
- `SWWAF_MAX_BANS` and `SWWAF_MAX_TRACKED_CLIENTS`, at 100,000 each;
- `SWWAF_LOG_REMOTE_BUFFER`;
- `SWWAF_STATE_WRITE_DELAY` and `SWWAF_STATE_COUNTER_INTERVAL`;
- the two anomaly netblock sizes and the log level.
Recommended: yes for the first five. The anomaly netblock sizes and the log level stay settings.
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.
why is max bans configurable? it needs to be bounded because we can’t have infinite memory use but it can be defined in code at some high value like 100000 and does not need to be tunable in any normal use case.
audit all settings and propose any here that can be defined in code and removed from settings.
Picked up for smallwebwaf's manager. The audit lists every setting that can become a constant in the code, each with the value it would take and why nobody needs to tune it, such as the ban count at 100,000. The list goes here for your yes before anything is removed.
Model: opus-5-5
For the genius-bar: audit every
SWRP_andSWWAF_setting on currentnextand post, as one comment here, the ones that can become a constant in the code, for sneak's yes. Write no code.Model: opus-5-5
Why max bans is a setting: nothing needs it to be. It only bounds memory, and no document gives an operator a reason to change it. Eleven more settings are like it.
Proposal: twelve settings become constants in the code.
nextata63b7e4. Every line number is ininternal/config/config.go.Fail the test clearly (confidence high, except where a line says otherwise)
SWWAF_MAX_BANS(line 508, default5000) becomes 100,000. It only bounds memory. See the catch below.SWWAF_MAX_TRACKED_CLIENTS(line 467, default20000) becomes 100,000. It only bounds memory. The GeoJS answers, one per client, are already fixed at 100,000. See the catch below.SWWAF_LOG_REMOTE_BUFFER(line 532, default10000) becomes 10,000 lines. It only bounds memory while the syslog server is slow or down. Stdout carries every line whatever happens.SWWAF_METRICS_TOP_N(line 518, default50) becomes 50. It only bounds the number of metric series. The other AS numbers and countries are summed asother, and the request log names each one.SWWAF_STATE_WRITE_DELAY(line 511, default10s) becomes 10 seconds. It is an internal timing: a burst of ban changes becomes one write ofbans.json. Only a hard kill loses those 10 seconds.SWWAF_STATE_COUNTER_INTERVAL(line 512, default15m) becomes 15 minutes. It is an internal timing: how often every state file is written. An orderly stop writes them all, so only a hard kill loses up to 15 minutes of counters.SWWAF_REPUTATION_CACHE_TTL(line 499, default24h) becomes 24 hours. It is a cache time: how long a DNS blocklist verdict or an AbuseIPDB score is used.SWWAF_REPUTATION_TIMEOUT(line 500, default2s) becomes 2 seconds. It is an internal timing: how long one DNS blocklist query or AbuseIPDB check may take. Those are made in the background, so no request waits for them.SWWAF_LOOKUP_TIMEOUT(line 481, default800ms) becomes 800 milliseconds. Confidence medium. It is an internal timing: how long a new client's first request waits for GeoJS. The catch: it must stay underSWRP_TIMEOUT_MS(default2000), which stays a setting. An operator who lowers that one below about a second could no longer lower this one to match, and requests waiting for GeoJS would getSWRP_DEFAULT_DISPOSITION.The catch on the two table sizes
bans.jsonagain 10 seconds after a ban changes.bans.jsonis about 120 MiB and a fullclients.jsonabout 100 MiB. Today they are 6 MiB and 20 MiB. Disk writes for the two files rise from about 2.5 GiB a day to about 20 GiB.Fail less clearly (confidence medium)
SWWAF_ANOMALY_NET_V4_PREFIX(line 548, default24) andSWWAF_ANOMALY_NET_V6_PREFIX(line 549, default48) become /24 and /48. They size the netblock around a client for the anomaly alerts, which block nothing. A /24 and a /48 are the smallest netblocks routed on the internet. A netblock of any other size can be named inSWWAF_WATCH_NETS.SWWAF_LOG_LEVEL(line 515, defaultinfo) becomesinfo. No message is logged atdebug.warnanderroronly hideservewaf's own messages, such as the line of settings at start, never a request line.rproxyhas no such setting and writes atinfo.Judgement calls: left as settings
SWRP_TIMEOUT_MS: an internal timing by the test, but one of the settings you listed forrproxyyourself (#165 (comment)).SWWAF_BLOCKLIST_REFRESH: a cache time by the test. It also decides how soon an edit to a list you host yourself reaches eachservewaf, such as the fileSWWAF_ASN_LIMIT_PERCENT_URLnames. No one figure suits both that and a list such as Spamhaus DROP, whose terms forbid fetching more than once an hour and call once a day enough.SWWAF_ABUSEIPDB_DAILY_BUDGET: sized by the operator's AbuseIPDB plan.SWWAF_ALERT_COOLDOWNandSWWAF_ALERT_MAX_PER_HOUR: they fit the flow of alerts to where it goes, a phone or a log collector.SWWAF_WAF_BODY_LIMIT: its size could be a constant, but the setting would stay as the switch for body inspection, so nothing would be removed.Not checked
docs/state-files.md. Nothing was measured, memory use included.For the manager's plan, if approved
README.md,docs/settings.mdandSPEC.md. "Fixed limits" indocs/settings.mdgains its figure. No old name is kept.docs/state-files.md, and inSPEC.mdthat a state file is written in well under a second and that the volume holds a few tens of MiB.Question: remove these twelve settings, each becoming the constant shown above?
Example: today
SWWAF_MAX_BANS=20000in a compose file changes how many bansservewafkeeps. After removal that line does nothing, and everyservewafkeeps up to 100,000.Putting one back later is its line in
internal/configand its rows in the documents.Model: fable-5-1
The audit above is ready for sneak's yes. Its question is at the end: should these twelve settings be removed, each becoming the constant shown? It recommends all listed. One cost to weigh: at 100,000 bans and 100,000 clients, the two state files grow from 6 and 20 MiB to about 120 and 100 MiB, and disk writes from about 2.5 GiB a day to about 20 GiB.
Model: opus-5-5
read and write all of the json files to disk as zstd compressed.
SWWAF_METRICS_TOP_N should be default to 100
SWWAF_REPUTATION_CACHE_TTL should default to 6h and should remain configurable and should be named SWWAF_IP_REPUTATION_CACHE_TTL - ambiguous and unclear names are VERY BAD and should be avoided EVERYWHERE ALWAYS.
SWWAF_REPUTATION_TIMEOUT (line 500, default 2s) becomes 2 seconds. It is an internal timing: how long one DNS blocklist query or AbuseIPDB check may take. Those are made in the background, so no request waits for them.
SWWAF_REPUTATION_TIMEOUT should be renamed - wtf is a reputation timeout? it should also be _MS for units. 2000 is an ok default but it should be configurable.
SWWAF_LOOKUP_TIMEOUT (line 481, default 800ms) becomes 800 milliseconds. Confidence medium. It is an internal timing: how long a new client's first request waits for GeoJS.
LOOKUP_TIMEOUT is ambiguous and must be renamed - it also needs _MS for units. what is it looking up? a user must be able to understand a setting in isolation without referring to the docs every time.
The catch: it must stay under SWRP_TIMEOUT_MS (default 2000), which stays a setting. An operator who lowers that one below about a second could no longer lower this one to match, and requests waiting for GeoJS would get SWRP_DEFAULT_DISPOSITION.
SWRP_TIMEOUT_MS is also totally ambiguous and must be renamed. i have no idea what it means and therefore a user doesn't know what it means. is it a request timeout? a decider timeout? a backend timeout? a reputation service timeout? stop wasting the user's time.
Recorded from sneak's answer above, for smallwebwaf's manager:
SWWAF_METRICS_TOP_Nstays a setting, default 100.SWWAF_REPUTATION_CACHE_TTLstays a setting, default 6 hours, renamedSWWAF_IP_REPUTATION_CACHE_TTL.SWWAF_REPUTATION_TIMEOUTstays a setting, default 2000. Its new name says what it times, the DNS blocklist and AbuseIPDB checks, and ends in_MS.SWWAF_LOOKUP_TIMEOUTstays a setting. Its new name says what is looked up, the client address's location, and ends in_MS.SWRP_TIMEOUT_MSis renamed to say which wait it limits: how longrproxywaits forservewaf's answer.Still open, for sneak: the eight he did not mention. Do they become constants as proposed?
SWWAF_MAX_BANSandSWWAF_MAX_TRACKED_CLIENTS, at 100,000 each;SWWAF_LOG_REMOTE_BUFFER;SWWAF_STATE_WRITE_DELAYandSWWAF_STATE_COUNTER_INTERVAL;Recommended: yes for the first five. The anomaly netblock sizes and the log level stay settings.
Model: opus-5-5