Upload Probe

Measure the caller's UPLOAD throughput. Deliberately unauthenticated.

Why upload, and why a probe at all: a video call is gated by UPLINK, and every signal the browser hands us for free measures the downlink. navigator.connection.downlink is a downlink estimate, it is Chromium-only (absent on Safari and Firefox), effectiveType lumps good fibre and a mediocre phone into the same '4g' bucket, and Chrome rounds and caps the number anyway. Asymmetric connections are the norm, so a teacher on 200 down / 2 up would be told video is fine and would then fail in front of a class. That is worse than saying nothing, because they would believe it.

So the client POSTs a known number of bytes and times it. The server's only job is to consume them and say how many arrived.

Unauthenticated on purpose: the page that calls this is the one that has to work when the app does not, so it has no token to send. That makes the abuse surface the whole design problem, and it is handled three ways:

1. RATE LIMIT, by the shared limiter, which keys anonymous callers on an ingress-controlled IP rather than the client-spoofable left-most X-Forwarded-For. 10 requests a minute against a 1 MiB cap puts the ceiling at 10 MiB per minute per IP.
2. HARD BYTE CAP, enforced twice. Content-Length is refused up front so a large upload never starts, and the stream is counted as it arrives so a lying or absent Content-Length cannot get past it either.
3. NEVER BUFFERED. The chunks are counted and dropped, never accumulated and never written anywhere. Memory stays flat no matter what is sent, which is what stops this being a way to push a pod to its 8 GiB limit.

Returns the byte count rather than a timing: the round trip is the thing being measured and only the client can see the whole of it.