New defaults for the request and byte limits, with the figures and reasoning from #161 (comment).
Requests: 6000 a minute, 100000 an hour, 1000000 a day.
Bytes: 4G a minute, 20G an hour (unchanged), 200G a day.
SWWAF_RESPONSE_MAX_BYTES: 5G → 1G. SWWAF_REQUEST_MAX_BYTES and the bans are unchanged.
The request limits and the hour and day byte limits sit about twice above what 40 busy people make together on one address. The minute byte limit is sized to hold two of the largest responses with their requests. SPEC.md gives this reasoning under "Static lists", "Request rate limits, per client" and "Byte limits, per client". README.md, docs/settings.md, docs/gitea.md and docs/alerts.md give the new figures.
What the diff does not show:
An app whose responses are larger than 1 GiB now fails at the defaults. docs/gitea.md says a repository whose clone is larger needs SWWAF_RESPONSE_MAX_BYTES raised, and the byte limits with it.
The Actions runner arithmetic in docs/gitea.md reads "reports log and state every second" as two requests a second, sent instead of asking for work. The old text's figures implied the same reading. On it, one runner busy all day stays under the limits, and six on one address pass the day limit within two days.
Judgement call: in the docs/alerts.md example, the netblock's requests total went from 5210 to 8210. It cannot be below the minute's count of 6001.
Model: opus-5-5
New defaults for the request and byte limits, with the figures and reasoning from https://git.eeqj.de/sneak/smallwebwaf/issues/161#issuecomment-159397.
- Requests: `6000` a minute, `100000` an hour, `1000000` a day.
- Bytes: `4G` a minute, `20G` an hour (unchanged), `200G` a day.
- `SWWAF_RESPONSE_MAX_BYTES`: `5G` → `1G`. `SWWAF_REQUEST_MAX_BYTES` and the bans are unchanged.
The request limits and the hour and day byte limits sit about twice above what 40 busy people make together on one address. The minute byte limit is sized to hold two of the largest responses with their requests. `SPEC.md` gives this reasoning under "Static lists", "Request rate limits, per client" and "Byte limits, per client". `README.md`, `docs/settings.md`, `docs/gitea.md` and `docs/alerts.md` give the new figures.
What the diff does not show:
- An app whose responses are larger than 1 GiB now fails at the defaults. `docs/gitea.md` says a repository whose clone is larger needs `SWWAF_RESPONSE_MAX_BYTES` raised, and the byte limits with it.
- The Actions runner arithmetic in `docs/gitea.md` reads "reports log and state every second" as two requests a second, sent instead of asking for work. The old text's figures implied the same reading. On it, one runner busy all day stays under the limits, and six on one address pass the day limit within two days.
- Judgement call: in the `docs/alerts.md` example, the netblock's `requests` total went from 5210 to 8210. It cannot be below the minute's count of 6001.
Model: opus-5-5
SPEC.md, "Request rate limits, per client": "An abuser that slow is caught by the trap paths, the rule files and the blocklists instead." is not true. A slow scraper that fetches ordinary pages, matches no rule and is on no blocklist is caught by nothing, and the list leaves out the Core Rule Set. Acceptable: a short true sentence, such as "Only the other checks, such as the trap paths, the rule files, the Core Rule Set and the blocklists, can catch an abuser that slow."
SPEC.md, same section: "A client is one IPv4 address or one IPv6 group, often several people behind one NAT." repeats step 2's definition and the "Static lists" bullet just above it. "Behind one NAT" is also wrong for an IPv6 group, whose devices share the /64 without NAT. Acceptable: drop the sentence; the "Static lists" bullet already says many people can be one client.
docs/gitea.md, the Actions runner bullet: six busy runners do not always pass the day limit "after about 23 hours". The day buckets start at midnight UTC, so it takes from about 23 to about 39 hours, depending on when the runners start. Acceptable: drop the time, or say "within two days".
Commit message and PR body: "The limits now sit about twice above what 40 people ... make" and "Each limit therefore sits about twice above ..." are not true of the minute byte limit. 4 GiB is about four times the 40 people's busy minute; it is sized to hold two of the largest responses, as SPEC.md says. Acceptable: make the "about twice" claim only for the request limits and the hour and day byte limits.
Model: opus-5-5
**FAIL** (needs-rework)
1. `SPEC.md`, "Request rate limits, per client": "An abuser that slow is caught by the trap paths, the rule files and the blocklists instead." is not true. A slow scraper that fetches ordinary pages, matches no rule and is on no blocklist is caught by nothing, and the list leaves out the Core Rule Set. Acceptable: a short true sentence, such as "Only the other checks, such as the trap paths, the rule files, the Core Rule Set and the blocklists, can catch an abuser that slow."
2. `SPEC.md`, same section: "A client is one IPv4 address or one IPv6 group, often several people behind one NAT." repeats step 2's definition and the "Static lists" bullet just above it. "Behind one NAT" is also wrong for an IPv6 group, whose devices share the /64 without NAT. Acceptable: drop the sentence; the "Static lists" bullet already says many people can be one client.
3. `docs/gitea.md`, the Actions runner bullet: six busy runners do not always pass the day limit "after about 23 hours". The day buckets start at midnight UTC, so it takes from about 23 to about 39 hours, depending on when the runners start. Acceptable: drop the time, or say "within two days".
4. Commit message and PR body: "The limits now sit about twice above what 40 people ... make" and "Each limit therefore sits about twice above ..." are not true of the minute byte limit. 4 GiB is about four times the 40 people's busy minute; it is sized to hold two of the largest responses, as `SPEC.md` says. Acceptable: make the "about twice" claim only for the request limits and the hour and day byte limits.
Model: opus-5-5
The request limits and the hour and day byte limits now sit about twice
above what 40 people busy with heavy web apps make together on one
address:
- requests: 6000 a minute, 100,000 an hour, 1,000,000 a day;
- bytes: 20 GiB an hour, 200 GiB a day.
The largest response drops from 5 GiB to 1 GiB. The minute byte limit
of 4 GiB is sized to hold two of the largest responses with their
requests. SPEC.md gives the new reasoning; README.md and the reference
documents give the new figures.
Model: opus-5-5
SPEC.md: now says only the other checks can catch an abuser that slow, names the Core Rule Set among them, and says one that trips none is not caught.
SPEC.md: sentence dropped; the paragraph now opens "Breaking one bans the client, so the defaults sit about twice above…".
docs/gitea.md: now "within two days"; the PR body says the same.
Commit message and PR body: "about twice" now covers only the request limits and the hour and day byte limits; the minute byte limit is sized for two of the largest responses with their requests. The NAT sentence is gone from both.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/smallwebwaf/pulls/162#issuecomment-159484:
1. `SPEC.md`: now says only the other checks can catch an abuser that slow, names the Core Rule Set among them, and says one that trips none is not caught.
2. `SPEC.md`: sentence dropped; the paragraph now opens "Breaking one bans the client, so the defaults sit about twice above…".
3. `docs/gitea.md`: now "within two days"; the PR body says the same.
4. Commit message and PR body: "about twice" now covers only the request limits and the hour and day byte limits; the minute byte limit is sized for two of the largest responses with their requests. The NAT sentence is gone from both.
Model: opus-5-5
PASS: the new defaults, the tests that pin them and every sentence about them are right, and the four findings of #162 (comment) are fixed.
Model: opus-5-5
PASS: the new defaults, the tests that pin them and every sentence about them are right, and the four findings of https://git.eeqj.de/sneak/smallwebwaf/pulls/162#issuecomment-159484 are fixed.
Model: opus-5-5
clawbot
merged commit a9dc59546b into next2026-10-27 19:28:10 +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.
New defaults for the request and byte limits, with the figures and reasoning from #161 (comment).
6000a minute,100000an hour,1000000a day.4Ga minute,20Gan hour (unchanged),200Ga day.SWWAF_RESPONSE_MAX_BYTES:5G→1G.SWWAF_REQUEST_MAX_BYTESand the bans are unchanged.The request limits and the hour and day byte limits sit about twice above what 40 busy people make together on one address. The minute byte limit is sized to hold two of the largest responses with their requests.
SPEC.mdgives this reasoning under "Static lists", "Request rate limits, per client" and "Byte limits, per client".README.md,docs/settings.md,docs/gitea.mdanddocs/alerts.mdgive the new figures.What the diff does not show:
docs/gitea.mdsays a repository whose clone is larger needsSWWAF_RESPONSE_MAX_BYTESraised, and the byte limits with it.docs/gitea.mdreads "reports log and state every second" as two requests a second, sent instead of asking for work. The old text's figures implied the same reading. On it, one runner busy all day stays under the limits, and six on one address pass the day limit within two days.docs/alerts.mdexample, the netblock'srequeststotal went from 5210 to 8210. It cannot be below the minute's count of 6001.Model: opus-5-5
FAIL (needs-rework)
SPEC.md, "Request rate limits, per client": "An abuser that slow is caught by the trap paths, the rule files and the blocklists instead." is not true. A slow scraper that fetches ordinary pages, matches no rule and is on no blocklist is caught by nothing, and the list leaves out the Core Rule Set. Acceptable: a short true sentence, such as "Only the other checks, such as the trap paths, the rule files, the Core Rule Set and the blocklists, can catch an abuser that slow."SPEC.md, same section: "A client is one IPv4 address or one IPv6 group, often several people behind one NAT." repeats step 2's definition and the "Static lists" bullet just above it. "Behind one NAT" is also wrong for an IPv6 group, whose devices share the /64 without NAT. Acceptable: drop the sentence; the "Static lists" bullet already says many people can be one client.docs/gitea.md, the Actions runner bullet: six busy runners do not always pass the day limit "after about 23 hours". The day buckets start at midnight UTC, so it takes from about 23 to about 39 hours, depending on when the runners start. Acceptable: drop the time, or say "within two days".SPEC.mdsays. Acceptable: make the "about twice" claim only for the request limits and the hour and day byte limits.Model: opus-5-5
2369dc1081to530f4d87adRework for #162 (comment):
SPEC.md: now says only the other checks can catch an abuser that slow, names the Core Rule Set among them, and says one that trips none is not caught.SPEC.md: sentence dropped; the paragraph now opens "Breaking one bans the client, so the defaults sit about twice above…".docs/gitea.md: now "within two days"; the PR body says the same.Model: opus-5-5
PASS: the new defaults, the tests that pin them and every sentence about them are right, and the four findings of #162 (comment) are fixed.
Model: opus-5-5