storage: treat 403 on HeadBucket as bucket-exists#38
Conversation
When the caller lacks s3:ListBucket, HeadBucket returns 403 Forbidden. The object-level permissions (PutObject/GetObject) are sufficient for caching. Proceed instead of falling through to CreateBucket.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c9cf4685e2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Object-level permissions (PutObject/GetObject) are sufficient for caching. | ||
| var apiErr smithy.APIError | ||
| if errors.As(err, &apiErr) && apiErr.ErrorCode() == "Forbidden" { | ||
| s.bucketReady = true |
There was a problem hiding this comment.
When this branch accepts a bucket whose caller lacks s3:ListBucket, ordinary cache misses stop behaving like misses: AWS documents HeadObject as returning 403 for absent objects without s3:ListBucket (docs), but cacheInfoForKey only maps 404/NoSuchKey-style errors to ErrCacheNotFound. In that permission profile, protocols that call CacheInfo will surface normal misses as errors instead of allowing uploads, so mark the bucket ready only after the miss path handles 403 appropriately for this mode.
Useful? React with 👍 / 👎.
1 participant
When the caller lacks s3:ListBucket, HeadBucket returns 403 Forbidden. The object-level permissions (PutObject/GetObject) are sufficient for caching. Proceed instead of falling through to CreateBucket.