fix(core): percent-encode object keys in raw-signed backend URLs

[alukach]

Problem

Multipart uploads to keys containing = (e.g. Hive-style partition paths like by_country/country_iso=ETH/ETH.pmtiles) fail with 403 SignatureDoesNotMatch at CreateMultipartUpload. Single PUTs on the same keys work. Reported downstream as source-cooperative/data.source.coop#180, where large unsplittable files (PMTiles) on partition paths cannot be uploaded at all (single PUT is capped by the Workers ~100 MB body limit).

Root cause

Raw-signed operations (multipart Create/UploadPart/Complete/Abort) build their backend URL in build_backend_url by splicing the decoded key into a string. url::Url leaves = — and the rest of ! ( ) : @ + , ; $ & ' — literal in paths, so the request went out and was signed with the literal byte. S3 (and MinIO — s3utils.EncodePath) reconstruct the SigV4 canonical URI by strict-encoding the decoded path (= → %3D), computing a different signature.

Presigned CRUD ops already encode with object_store's STRICT_ENCODE_SET, which is why plain PUT/GET on these keys worked — the asymmetry was only in the raw-signed path.

Fix

Encode the assembled prefix + key with the SigV4 strict set (RFC 3986 unreserved chars, / kept as the segment separator) before splicing. The URL string returned by build_backend_url is both the signing input (sign_s3_request signs Url::parse(url).path(), which does not re-encode %) and the wire bytes (send_raw passes the string to the Fetch Request constructor), so signature and wire stay byte-identical — no reliance on backend-specific canonicalization. One change covers all three call sites (execute_multipart, build_streaming_forward, execute_delete_objects; the last has no key in its URL). percent-encoding was already a direct dependency.

Keys legitimately containing a literal %3D round-trip correctly (% is encoded → %253D). Query strings (uploadId, partNumber) were already handled via form_urlencoded and are untouched, as is inbound signature verification (signing_path, #103).

Tests

• Unit (crates/core/src/backend/multipart.rs): special chars encoded + Url::parse round-trip (canonical URI == wire path), full AWS-special set with / preserved, literal-%3D double-encoding.
• Integration (tests/integration/test_integration.py): parametrized multipart round-trip (upload via transfer manager → GET back → delete) against MinIO for a country_iso=ETH partition key and a kitchen-sink specials key.

Verified fail-before/pass-after locally with scripts/integration-test.sh:

• Before the fix: both parametrized cases fail with SignatureDoesNotMatch at CreateMultipartUpload — exact reproduction of the downstream issue.
• After the fix: full integration suite green (24 passed, 4 OIDC tests self-skipped locally), plus cargo test (126 tests), cargo fmt, clippy, and wasm cargo check.

Known limitation surfaced (pre-existing, out of scope)

Characters in object_store's PathPart INVALID set (*, %, ~, #, ?, |, \, {, }, [, ], <, >, ", ^) are silently rewritten in the logical key by the presigned CRUD path (Path::from encodes * → %2A, so the backend object is created/fetched under the mangled key). Presigned PUT+GET round-trips are self-consistently mangled, but a byte-faithful multipart write of such a key can't be read back through the presigned GET. * is therefore excluded from the integration test's specials key (noted in a comment). Worth a follow-up issue if byte-faithful keys for those characters matter.

Also syncs Cargo.lock with the 0.6.3 release version bump (main's lock was stale; any local cargo build regenerates the same diff).

🤖 Generated with Claude Code

[github-actions]

🚀 Latest commit deployed to https://multistore-proxy-pr-105.development-seed.workers.dev

• Date: 2026-07-10T19:19:01Z
• Commit: d80b460