feat(sts): accept AssumeRoleWithWebIdentity from form-encoded POST bodies

[alukach]

AWS SDKs send query-protocol operations as a form-encoded POST body with no query string at all, but the worker only ever surfaced the query string to the router. The STS handler reads its parameters from RequestInfo::form_body, which stayed None, so every SDK-shaped request fell through to the S3 pipeline.

multistore 0.7.0 (developmentseed/multistore#112, pulled in by #190) added RequestParts::absorb_form_body for exactly this. The dep bump alone does not enable it — the runtime has to call it, which is what this PR does.

Behavior

POST /.sts with Action=AssumeRoleWithWebIdentity&RoleArn=_default&WebIdentityToken=… in the body:

	before	after
response	400 InvalidRequest: unsupported POST operation	routed to the STS handler

Verified locally against wrangler dev with the stub API and a throwaway OIDC key, rebuilding the worker each way to confirm the difference is this change and not a stale isolate.

Safety

absorb_form_body is a no-op passthrough for every request shape that is not a form-encoded POST, and it rebuilds the body from the collected bytes — so a mislabeled S3 write (Content-Type is client-controlled: CompleteMultipartUpload, DeleteObjects) still reaches the gateway with its payload intact. Collection is skipped entirely for a form POST with a missing or oversized Content-Length rather than buffering it into WASM memory.

Tests

• test_sts_form_encoded_body_reaches_the_sts_handler — needs no identity token, so it runs on fork PRs. Asserts the response is an STS rejection (InvalidIdentityToken) rather than the S3 fall-through; the status code alone does not discriminate, since both are 400. Fails on main.
• test_sts_exchange_accepts_a_form_encoded_body — the positive path, under the existing needs_token gate.

Full local integration run: 24 passed, 11 skipped (credentialed tier, no GitHub OIDC token locally).

Scope

Part of #184. This is one of the two blockers for a true SDK drop-in; the other is #185 — AWS SDKs validate RoleArn client-side (min 20 chars), so _default is rejected before the request is ever sent. Both are needed before boto3.client("sts", endpoint_url=…) works unmodified.

🤖 Generated with Claude Code

[claude]

Claude finished @alukach's task in 3m 2s —— View job

---

Review of PR #196

• Gather context (diff, changed files)
• Review src/lib.rs changes
• Review tests/test_writes.py changes
• Post findings

✅ No blocking issues — safe to merge.

• The absorb_form_body call is placed before path-mapping and before the .with_form_body(...) builder call is threaded into every RequestInfo, not just the /.sts route (src/lib.rs:143-146, src/lib.rs:328). For any non-form-encoded request (all S3 reads/writes), parts.form_body stays None, so .with_form_body(None) is a no-op — consistent with the PR's stated safety guarantee that a mislabeled S3 write's payload reaches the gateway intact.
• The reassignment to mut js_body/mut parts (src/lib.rs:125,143) correctly threads the rebuilt body back into the later gateway.handle_request(...) call (src/lib.rs:332), so nothing reads the pre-absorption body by mistake.
• Test coverage is good: test_sts_form_encoded_body_reaches_the_sts_handler (needs no token, so it runs on fork PRs) asserts on InvalidIdentityToken rather than just the status code — important since both the old (S3 fall-through) and new (STS rejection) behavior return 400, so the status code alone wouldn't catch a regression back to the old behavior.
• Minor/non-blocking: the absorption call runs before the STS-disabled fail-closed check (src/lib.rs:173), so a POST /.sts while AUTH_AUDIENCE is unset still pays for form-body collection before being rejected with 501. Bounded by the crate's own missing/oversized-Content-Length skip, so not a real risk — just a candidate for reordering if it ever matters.

[github-actions]

🚀 Latest commit deployed to https://source-data-proxy-pr-196.source-coop.workers.dev

• Date: 2026-07-27T05:56:40Z
• Commit: eda02db