The per-client byte budget ignores admitted requests until they finish. Concurrent requests can all observe the same positive balance, so a client's overshoot scales with concurrent work rather than one request's cap.
guard calls budget.allow, runs the entire handler, then calls budget.charge. The operations are individually mutex-protected, but there is no reservation or accounting for in-flight work. This affects both IP-keyed and signed-subject budgets.
Evidence from the project review:
- Instantiate
server.Handler with MaxClientBytes=1, ClientWindow=1h, and UploadSize=1024.
- Start eight uploads from the same source IP, blocking each body reader until all eight requests have passed admission.
- Release the readers with 1024-byte bodies.
- All eight requests return 200 and consume 8192 bytes against the one-byte budget.
Relevant code: allow/charge, handler admission.
Acceptance criteria:
- Define and enforce a finite per-client bound on outstanding admitted work and total possible overshoot under concurrency.
- Preserve unthrottled admitted transfers: admission limits must not shape measurement traffic.
- Any reservation/admission state is released or settled correctly on completion, cancellation, and write/read failure.
- Test concurrent uploads and downloads, signed subjects and IP identities, budget refill, and cancellation under the race detector.
- Update SRV-8 wording, public options/docs as needed, the test matrix, and changelog.
Design should consider legitimate multi-flow measurements before choosing reservations, per-client admission limits, or another mechanism; serializing all client traffic would bias the test.
Related: #1, SRV-8, SRV-9, INV-1. Spec/architecture changes require confirmation before commit.
The per-client byte budget ignores admitted requests until they finish. Concurrent requests can all observe the same positive balance, so a client's overshoot scales with concurrent work rather than one request's cap.
guardcallsbudget.allow, runs the entire handler, then callsbudget.charge. The operations are individually mutex-protected, but there is no reservation or accounting for in-flight work. This affects both IP-keyed and signed-subject budgets.Evidence from the project review:
server.HandlerwithMaxClientBytes=1,ClientWindow=1h, andUploadSize=1024.Relevant code: allow/charge, handler admission.
Acceptance criteria:
Design should consider legitimate multi-flow measurements before choosing reservations, per-client admission limits, or another mechanism; serializing all client traffic would bias the test.
Related: #1, SRV-8, SRV-9, INV-1. Spec/architecture changes require confirmation before commit.