feat: send bytes= query param on upload measurements

[devandrepascoa]

Adds the upload size signal needed by the speed.cloudflare.com server cap.

Upload (POST /__up) requests now include bytes=<size>, matching download requests, so the server can enforce a byte ceiling on the upload body.

No user-visible behavior change for normal clients: bytes= matches the upload body size.

[ask-bonk]

Summary

This PR makes the bytes=<size> query param unconditional on bandwidth measurement requests so that upload (POST /__up) requests now carry it too, matching download requests. This gives the server the upload-size signal it needs to enforce a byte ceiling on the upload body.

The single-line change in BandwidthEngine.ts:348 replaces the download-only short-circuit assignment (isDown && (qsParams.bytes = ...)) with an unconditional qsParams.bytes = ${numBytes}``.

Assessment

Correctness: Verified. The upload body is produced by genContent(numBytes) (line 360), which returns '0'.repeat(numBytes) — exactly numBytes ASCII bytes. So the bytes= value provably matches the upload body size, as the PR description claims. No behavioral risk for normal clients.

Style: Good. Dropping the && short-circuit idiom in favor of a plain assignment is cleaner now that the value is no longer conditional, and it remains consistent with the surrounding code.

Security: The change is the enabling half of a server-side byte ceiling. The cap itself is enforced server-side; this is just the client-supplied size signal. No new client-side concern. (Note: a custom/malicious client could still send bytes= that does not match the actual body — but enforcing that mismatch is necessarily a server responsibility, so nothing actionable here.)

Verification: pnpm build succeeds and all 93 unit tests pass on this branch.

LGTM — small, correct, and well-scoped. One optional note left inline.

[ask-bonk]

Optional: consider a brief comment here noting that bytes= is now sent for uploads too (not just downloads) and must stay in sync with the genContent(numBytes) body below, so future refactors don't accidentally desync the advertised size from the actual upload body. Not blocking — both are derived from the same numBytes, so they are correct as written.

[ask-bonk]

Review posted on PR #122.

Review summary

What it changes: A single-line change in src/engines/BandwidthEngine/BandwidthEngine.ts:348. It replaces the download-only conditional assignment isDown && (qsParams.bytes = ${numBytes}) with an unconditional qsParams.bytes = ${numBytes}``, so upload (POST /__up) requests now also carry `bytes=`. This gives the server the upload-size signal needed to enforce a byte ceiling on the upload body.

Findings:

• Correctness — OK. Verified that the upload body comes from genContent(numBytes), which returns '0'.repeat(numBytes) — exactly numBytes ASCII bytes. So bytes= provably matches the actual upload body size, confirming the PR's "no user-visible behavior change" claim.
• Style — OK. Dropping the && short-circuit idiom for a plain assignment is cleaner now that the value is unconditional, and consistent with surrounding code.
• Security — no new concern. This is the client-side size signal; the actual cap is enforced server-side. A malicious client could still send a mismatched bytes=, but validating that is necessarily a server responsibility.
• Verification: pnpm build succeeds and all 93 unit tests pass on the branch.

Comments posted to PR #122:

• One review summary comment.
• One optional (non-blocking) inline note on line 348 suggesting a brief comment to keep the advertised bytes= size in sync with the genContent(numBytes) body in future refactors.

Overall: small, correct, and well-scoped — LGTM with only an optional suggestion. No commits pushed.

github run