[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 two new Appwrite Storage features shipping in the Stardust release: virtual folders (a
Confidence Score: 5/5Pure documentation additions with no runtime code changes; safe to merge once content is finalized. All changes are markdoc content and a single Svelte nav update. The new pages are internally consistent, the Go SDK example now includes the required import block, and the limitations section accurately reflects unsupported features. No logic that could regress existing behavior. No files require special attention. Important Files Changed
Reviews (4): Last reviewed commit: "Add folders concept and docs" | 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.)