fix(s3): honor Tags in CreateBucketConfiguration

[vieiralucas]

Summary

CreateBucket accepted the Tags tag set that was added to CreateBucketConfiguration in the 2025 S3 API, but dropped it: create_bucket only pulled LocationConstraint out of the body, so the bucket came out untagged and GetBucketTagging answered NoSuchTagSet.

That path matters for Terraform. The AWS provider (6.x) tags a bucket this way on create and skips PutBucketTagging when the create succeeds, so an aws_s3_bucket with tags applied cleanly and then read back tags = {}.

Verified against the vendored Smithy model before implementing: com.amazonaws.s3#CreateBucketConfiguration does carry a Tags member targeting TagSet (non-flattened, xmlName: "Tag"), and the Rust SDK serializes it as <Tags><Tag><Key/><Value/></Tag></Tags> — the same shape parse_tagging_xml already handles for PutBucketTagging.

The bug underneath it

Requiring s3:TagResource (below) did not work at first, and the reason turned out to be a separate defect one layer down. The AWS SDKs send CreateBucket as PUT /<bucket>/, and streaming_route in crates/fakecloud-core/src/dispatch.rs read the trailing slash as an object upload, so the body went to the handler unbuffered. Everything that runs before the handler therefore saw an empty body — IAM enforcement could not read CreateBucketConfiguration at all. The handler itself was unaffected, because it drains the stream into req.body for non-object PUTs, which is why the tags applied even though the authorization layer could not see them.

This was not limited to tags: with the old predicate, a trailing-slash CreateBucket also dropped LocationConstraint (so any non-us-east-1 create sent that way would have failed IllegalLocationConstraintException), and PUT /bucket/?tagging saw an empty body too.

The gate and the router had each derived "where does the bucket end and the key begin" separately, and drifted — twice (the trailing slash, then a doubled slash, then the virtual-hosted bucket-in-path shape). So the router's derivation is now extracted into s3_routing_path and the gate calls it: streaming requires the routed path to split into a bucket and a non-empty key, by the same split-and-drop-empty rule path_segments uses. They are the same code now and cannot drift again.

Changes

• parse the <Tags> tag set out of CreateBucketConfiguration and store it on the new bucket
• validate_tags runs before any state mutation, so duplicate keys and aws:-prefixed keys fail with InvalidTag and no bucket is created
• persist the Tags subresource (bucket tags are not part of BucketMeta), written before meta.toml and before the in-memory insert, so a store failure leaves no half-created bucket; an untagged create deletes the subresource, so a previously half-written tags.toml can't be adopted by a later untagged create of the same name
• authorize a tagged create as s3:CreateBucket and s3:TagResource, per the model text on CreateBucketConfiguration$Tags; an untagged create still needs only s3:CreateBucket
• feed the create-time tag set to aws:RequestTag/<key> and aws:TagKeys
• fix streaming_route as described above

Test plan

• Unit (fakecloud-s3): tag set stored; no-tags case; InvalidTag on duplicate keys leaves no bucket; XML-entity round-trip; the CreateBucket + TagResource action pair (and that an untagged create yields only CreateBucket); request-tag extraction for both actions; helper gating on the CreateBucketConfiguration root; idempotent us-east-1 re-create does not re-apply the tag set.
• Unit (fakecloud-core): streaming_route for /b/, /b//, a real key ending in /, and the virtual-hosted bucket-in-path shape.
• E2E: create-with-tags (plus PutBucketTagging still replacing the set wholesale); duplicate-key rejection; tags surviving a restart; an untagged create clearing an orphan tags.toml; the s3:TagResource requirement; an aws:RequestTag-conditioned create.
• Each of the three behavioral fixes was verified by reverting it and confirming the new test fails (tag persistence → NoSuchTagSet after restart; orphan clear → inherited ghost tag; virtual-hosted gate → still streams).
• Suites: fakecloud-core 331 passed, fakecloud-s3 448+ passed, e2e s3 + s3_persistence + iam_enforcement + iam_enforcement_abac + s3_streaming_body + s3_aws_chunked + s3_access_points + s3_anonymous_access + s3_post_object + ecr all green, fakecloud-conformance --test s3 51 passed. cargo clippy --all-targets -- -D warnings and cargo fmt --check clean.

Surface sync

• Reference docs — website/content/docs/services/s3.md gains a "Bucket tags at create time" bullet; website/content/docs/reference/security.md updates the aws:RequestTag/<key> row for the CreateBucket tag set and its s3:TagResource requirement.
• SDKs / introspection — no change: this is AWS API behavior, not a /_fakecloud/* surface, so no first-party SDK touches it.
• Counts / metadata — unchanged: no new operation, service, or conformance variant, so conformance-baseline.json, the ops index, the README headline, and the GitHub repo description all stay as they are.
• README / AGENTS / CLAUDE / examples / changelog — checked, none of them assert CreateBucket tag behavior.

Known limitation (pre-existing, now documented)

Under virtual-hosted addressing real S3 treats the whole path as the key, so a key beginning with <bucket>/ is not representable — the router reads it as a client that put the bucket in the path. Nothing in a single request tells the two apart. Moved verbatim into s3_routing_path and now stated in its doc comment rather than implied.

Fixes #2553

🤖 Generated with Claude Code

https://claude.ai/code/session_015paJopoDarw6WeFFoZMDMf

---

Summary by cubic

CreateBucket now honors the Tags tag set in CreateBucketConfiguration, storing it on the new bucket so GetBucketTagging returns the tags immediately instead of NoSuchTagSet. This fixes the AWS Terraform provider (6.x) reading back tags = {} after a clean create.

A tagged create now also requires s3:TagResource alongside s3:CreateBucket and populates aws:RequestTag/* and aws:TagKeys, matching real S3. Fixes a dispatch bug where bucket-level PUTs like PUT /<bucket>/ were streamed unbuffered, so IAM enforcement saw an empty body; they now buffer through the same routing helper as object PUTs.

• Tag validation runs before any state mutation; duplicate and aws:-prefixed keys fail with InvalidTag and no bucket is created.
• Tags persist in their own subresource, written before bucket meta; an untagged create deletes any orphan tag file.

^{Written for commit c9c5308. Summary will update on new commits.}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.