[WIP] Stardust storage docs#3084
Conversation
Appwrite WebsiteProject ID: Website (appwrite/website)Project ID: Tip Global CDN and DDoS protection come free with every Sites deployment |
Greptile SummaryThis PR adds documentation for the new S3-compatible API for Appwrite Storage, including a reference docs page, an announcement blog post, a changelog entry, and a sidebar navigation link.
Confidence Score: 5/5Documentation-only changes with no runtime code; safe to merge after addressing the minor UploadPartCopy wording inaccuracy. All four changed files are Markdoc/Svelte documentation content with no application logic modified. The Go snippet now correctly includes its import block. The only new finding is a minor wording inaccuracy in the UploadPartCopy row. src/routes/docs/products/storage/s3/+page.markdoc — UploadPartCopy description wording and the previously flagged x-amz-server-side-encryption/Limitations discrepancy. Important Files Changed
Reviews (3): Last reviewed commit: "Add announcement blog and changelog" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| | Operation | Description | | ||
| | --- | --- | | ||
| | `PutObject` | Upload an object. Returns an `ETag`. Honors `Content-Type`, `x-amz-meta-*` user metadata, and `x-amz-server-side-encryption`. | |
There was a problem hiding this comment.
x-amz-server-side-encryption contradicts Limitations
The PutObject row says Appwrite "honors" x-amz-server-side-encryption, implying the header is acted upon. The Limitations section, however, lists "encryption configuration" as unsupported and returning NotImplemented. A reader uploading sensitive files with x-amz-server-side-encryption: AES256 set could reasonably believe their objects are encrypted at rest via the S3 API when they are not. If the header is silently accepted for tooling compatibility (like ACLs), clarify that explicitly — e.g. "accepted for compatibility; does not enable server-side encryption."
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/routes/docs/products/storage/s3/+page.markdoc
Line: 182
Comment:
**`x-amz-server-side-encryption` contradicts Limitations**
The `PutObject` row says Appwrite "honors" `x-amz-server-side-encryption`, implying the header is acted upon. The Limitations section, however, lists "encryption configuration" as unsupported and returning `NotImplemented`. A reader uploading sensitive files with `x-amz-server-side-encryption: AES256` set could reasonably believe their objects are encrypted at rest via the S3 API when they are not. If the header is silently accepted for tooling compatibility (like ACLs), clarify that explicitly — e.g. "accepted for compatibility; does not enable server-side encryption."
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| {fileId}-{fileName} | ||
| ``` | ||
|
|
||
| For example, uploading to the key `reports/january.pdf` creates a file whose name is `reports/january.pdf`, and the object is then listed under a canonical key such as `6710e2...f3-reports/january.pdf`. |
There was a problem hiding this comment.
This and the info box below sounds a little confusing at first, can we simplify?
2 participants
What does this PR do?
(Provide a description of what this PR does.)
Test Plan
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)
Related PRs and Issues
(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)
Have you read the Contributing Guidelines on issues?
(Write your answer here.)