Garage S3 API is not able to GET certain file formats (.png, .jpg) when used in Directus #579
Labels
No Label
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#579
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
https://directus.io/ (it seems to be using @aws-sdk/client-s3)
Context: If I use minio node js (with Garage S3 API!), I can upload and download images without issues. In Directus, I can upload and download .txt without issues.
Problem: I can upload .png or .jpg, but then I receive an error after the upload (possibly because Directus tries to GET the image after the POST). I'm not able to download .png or .jpg in Directus. Weirdly enough, in Directus, I'm able to listObjects to get metadata about the .jpg, .png and I'm also able to delete .jpg and .png. Just the fetching / GET doesn't work.
Error message in Directus logs:
Error Message in Garage Logs:
Garage Setup in Directus (running in Kubernetes):
force path style is on, because I didn't succeed yet in providing sub domain wildcard TLS in Kubernetes. Maybe that could be the issue. I kinda doubt it though.
I'm investigating the error myself and will do a pull request if/when I figure it out.
I just wanted to let you know and maybe you even have an idea what the problem could be.
So, I cloned the Directus repository (https://github.com/directus/directus) and implemented the S3 Driver with Minio (Node JS), instead of @aws-sdk/client-s3 (Node JS).
Turns out, ... I get basically the same error.
Directus Logs:
Garage Logs:
Super confusing.
I assume this is something Directus does internally?
I don't see anything strange in the signature calculation, however it looks like you are behind some kind of cloudflare proxy? Could it be that the proxy is rewriting some of your headers in the GET request (e.g. the Host header) and this is the reason why signatures do not match on either sides?
Eyoooooooooo!
That was the issue.
So I jumped to another DNS (Bunny CDN) that's easier to manage with and without proxy than CloudFlare:
CloudFlare with Proxy: Does not work
CloudFlare without Proxy: No idea, don't get TLS to work without proxy, CloudFlare (free tier) sometimes sucks hard
Bunny with Proxy: Does not work
Bunny without Proxy: -->>WORKS<<--
Weird.
Is this somehow fixable?
Technically, I intend to use the Garage API internally in the Kubernetes network as soon as I manage to make it work (had some issues with internal IP). So the problem can be fully avoided and I see the problem as solved for my use case.
However, is there not an incentive to make this work with Proxies and CDNs as well? That could be a real legitimate use case, e.g. caching.
Not sure this is fixable, it seems it depends on the way the proxy changes HTTP headers which is vendor-dependant and hard to predict. I think Garage works fine with some other reverse proxies such as Caddy. For the CDN use case, if the idea is to broadcast read-only content to a wide audience, then you can try using Garage's web endpoint which is publicly accessible without authentication.