sneak's milestones set what is built first: #13 and #14. SPEC.md follows them:
the "Build order" section becomes milestone 1, then milestone 2, then the rest of the present stages, less what the two milestones took;
the four size limits become two, REQUEST_MAX_BYTES and RESPONSE_MAX_BYTES, since smallwebwaf passes bodies through unchanged ("Choices made" on issue 13);
the GeoJS answers are kept in memory, and writing them to disk comes in a later milestone (sneak, #14 (comment)).
This is a spec change of its own after #9, so that PR's rework and review scope stay as they are.
Definition of done
SPEC.md on next says the above.
One docs-only PR to next, prettier-formatted.
Model: opus-5-5
sneak's milestones set what is built first: https://git.eeqj.de/sneak/smallwebwaf/issues/13 and https://git.eeqj.de/sneak/smallwebwaf/issues/14. `SPEC.md` follows them:
- the "Build order" section becomes milestone 1, then milestone 2, then the rest of the present stages, less what the two milestones took;
- the four size limits become two, `REQUEST_MAX_BYTES` and `RESPONSE_MAX_BYTES`, since smallwebwaf passes bodies through unchanged ("Choices made" on issue 13);
- the GeoJS answers are kept in memory, and writing them to disk comes in a later milestone (sneak, https://git.eeqj.de/sneak/smallwebwaf/issues/14#issuecomment-103016).
This is a spec change of its own after https://git.eeqj.de/sneak/smallwebwaf/pulls/9, so that PR's rework and review scope stay as they are.
## Definition of done
- `SPEC.md` on `next` says the above.
- One docs-only PR to `next`, prettier-formatted.
Model: opus-5-5
clawbot
self-assigned this 2026-09-25 11:01:47 +02:00
The spec in #9 has four body-size settings, as you asked in #5. There is one for each side of each direction:
the request body a client may send (CLIENT_REQUEST_MAX_BYTES);
the request body passed on to the app (UPSTREAM_REQUEST_MAX_BYTES);
the response body the app may send back (UPSTREAM_RESPONSE_MAX_BYTES);
the response body passed on to the client (CLIENT_RESPONSE_MAX_BYTES).
smallwebwaf forwards a body without changing it, so the request body a client sends is byte for byte the one the app receives, and the same holds for responses. Two limits on the same bytes means the lower one always decides and the higher one never does anything.
Milestone 1 therefore has one limit per direction: SWWAF_REQUEST_MAX_BYTES (default 100M) for request bodies and SWWAF_RESPONSE_MAX_BYTES (default 5G) for response bodies. The four timeouts stay four, because there the two sides differ: a slow client and a slow app are separate problems. This issue writes that into SPEC.md.
If you want the four size settings kept anyway, say so here; the milestone and the spec then keep four.
Model: opus-5-5
The spec in https://git.eeqj.de/sneak/smallwebwaf/pulls/9 has four body-size settings, as you asked in https://git.eeqj.de/sneak/smallwebwaf/issues/5. There is one for each side of each direction:
- the request body a client may send (`CLIENT_REQUEST_MAX_BYTES`);
- the request body passed on to the app (`UPSTREAM_REQUEST_MAX_BYTES`);
- the response body the app may send back (`UPSTREAM_RESPONSE_MAX_BYTES`);
- the response body passed on to the client (`CLIENT_RESPONSE_MAX_BYTES`).
smallwebwaf forwards a body without changing it, so the request body a client sends is byte for byte the one the app receives, and the same holds for responses. Two limits on the same bytes means the lower one always decides and the higher one never does anything.
Milestone 1 therefore has one limit per direction: `SWWAF_REQUEST_MAX_BYTES` (default 100M) for request bodies and `SWWAF_RESPONSE_MAX_BYTES` (default 5G) for response bodies. The four timeouts stay four, because there the two sides differ: a slow client and a slow app are separate problems. This issue writes that into `SPEC.md`.
If you want the four size settings kept anyway, say so here; the milestone and the spec then keep four.
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's milestones set what is built first: #13 and #14.
SPEC.mdfollows them:REQUEST_MAX_BYTESandRESPONSE_MAX_BYTES, since smallwebwaf passes bodies through unchanged ("Choices made" on issue 13);This is a spec change of its own after #9, so that PR's rework and review scope stay as they are.
Definition of done
SPEC.mdonnextsays the above.next, prettier-formatted.Model: opus-5-5
clarify what you mean by "the four size limits become two"
The spec in #9 has four body-size settings, as you asked in #5. There is one for each side of each direction:
CLIENT_REQUEST_MAX_BYTES);UPSTREAM_REQUEST_MAX_BYTES);UPSTREAM_RESPONSE_MAX_BYTES);CLIENT_RESPONSE_MAX_BYTES).smallwebwaf forwards a body without changing it, so the request body a client sends is byte for byte the one the app receives, and the same holds for responses. Two limits on the same bytes means the lower one always decides and the higher one never does anything.
Milestone 1 therefore has one limit per direction:
SWWAF_REQUEST_MAX_BYTES(default 100M) for request bodies andSWWAF_RESPONSE_MAX_BYTES(default 5G) for response bodies. The four timeouts stay four, because there the two sides differ: a slow client and a slow app are separate problems. This issue writes that intoSPEC.md.If you want the four size settings kept anyway, say so here; the milestone and the spec then keep four.
Model: opus-5-5