Part of #169. sneak, 4 November: the default request limits must suit programmatic API use, such as an automation fleet on another host, while still stopping abusive bots. sneak, on #179: there must be a per-minute limit; then, on #169 (comment), of 300 to 500 a minute; 500 was taken; and, on #179 (comment), 20,000 an hour. The numbers and their reasons are at #169 (comment); a change he makes to them is a small follow-up.
What to build
SWWAF_RATE_LIMIT_PER_MINUTE defaults to 500.
SWWAF_RATE_LIMIT_PER_HOUR defaults to 20000.
SWWAF_RATE_LIMIT_PER_DAY defaults to 300000.
The byte limits, the ban lengths and everything else stay as they are.
The tests that rely on the old defaults follow.
Documents
docs/settings.md, the README's "What it protects against", and "Request rate limits, per client" in SPEC.md give the new defaults and the reason for each, in place of the "40 busy people on one address" sizing: per minute, high enough for a fleet's busiest minute and a few first visits with an empty cache, and low enough to catch a client firing as fast as it can; per hour, high enough for an automation fleet at work and low enough to catch a scraper that keeps up about six requests a second; per day, to catch one that keeps up three or four a second around the clock. Say plainly what counting cannot catch: a client slower than that. docs/gitea.md's sums for Actions runners follow the new day limit.
Model: opus-5-5
Part of https://git.eeqj.de/sneak/smallwebwaf/issues/169. sneak, 4 November: the default request limits must suit programmatic API use, such as an automation fleet on another host, while still stopping abusive bots. sneak, on https://git.eeqj.de/sneak/smallwebwaf/pulls/179: there must be a per-minute limit; then, on https://git.eeqj.de/sneak/smallwebwaf/issues/169#issuecomment-167897, of 300 to 500 a minute; 500 was taken; and, on https://git.eeqj.de/sneak/smallwebwaf/pulls/179#issuecomment-168078, 20,000 an hour. The numbers and their reasons are at https://git.eeqj.de/sneak/smallwebwaf/issues/169#issuecomment-167815; a change he makes to them is a small follow-up.
## What to build
- `SWWAF_RATE_LIMIT_PER_MINUTE` defaults to `500`.
- `SWWAF_RATE_LIMIT_PER_HOUR` defaults to `20000`.
- `SWWAF_RATE_LIMIT_PER_DAY` defaults to `300000`.
- The byte limits, the ban lengths and everything else stay as they are.
- The tests that rely on the old defaults follow.
## Documents
`docs/settings.md`, the README's "What it protects against", and "Request rate limits, per client" in `SPEC.md` give the new defaults and the reason for each, in place of the "40 busy people on one address" sizing: per minute, high enough for a fleet's busiest minute and a few first visits with an empty cache, and low enough to catch a client firing as fast as it can; per hour, high enough for an automation fleet at work and low enough to catch a scraper that keeps up about six requests a second; per day, to catch one that keeps up three or four a second around the clock. Say plainly what counting cannot catch: a client slower than that. `docs/gitea.md`'s sums for Actions runners follow the new day limit.
Model: opus-5-5
clawbot
self-assigned this 2026-11-04 20:09:56 +01:00
Built in #179: the request limits now default to off per minute, 30000 per hour and 300000 per day, with the documents the issue names updated. The PR body lists three judgement calls on the wording.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/smallwebwaf/pulls/179: the request limits now default to `off` per minute, `30000` per hour and `300000` per day, with the documents the issue names updated. The PR body lists three judgement calls on the wording.
Model: opus-5-5
clawbot
changed title from Default request limits per hour and per day, sized for API use to Default request limits per minute, hour and day, sized for API use2026-11-04 21:48:53 +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 #169. sneak, 4 November: the default request limits must suit programmatic API use, such as an automation fleet on another host, while still stopping abusive bots. sneak, on #179: there must be a per-minute limit; then, on #169 (comment), of 300 to 500 a minute; 500 was taken; and, on #179 (comment), 20,000 an hour. The numbers and their reasons are at #169 (comment); a change he makes to them is a small follow-up.
What to build
SWWAF_RATE_LIMIT_PER_MINUTEdefaults to500.SWWAF_RATE_LIMIT_PER_HOURdefaults to20000.SWWAF_RATE_LIMIT_PER_DAYdefaults to300000.Documents
docs/settings.md, the README's "What it protects against", and "Request rate limits, per client" inSPEC.mdgive the new defaults and the reason for each, in place of the "40 busy people on one address" sizing: per minute, high enough for a fleet's busiest minute and a few first visits with an empty cache, and low enough to catch a client firing as fast as it can; per hour, high enough for an automation fleet at work and low enough to catch a scraper that keeps up about six requests a second; per day, to catch one that keeps up three or four a second around the clock. Say plainly what counting cannot catch: a client slower than that.docs/gitea.md's sums for Actions runners follow the new day limit.Model: opus-5-5
Built in #179: the request limits now default to
offper minute,30000per hour and300000per day, with the documents the issue names updated. The PR body lists three judgement calls on the wording.Model: opus-5-5
Default request limits per hour and per day, sized for API useto Default request limits per minute, hour and day, sized for API use