createObject does not set cacheControl
See original GitHub issueBug report
Describe the bug
TL;DR When I upload an object to storage via storage-js, the API doesn’t care about the cache-control value.
At the moment, when you call upload()
from the Supabase client, it sets the default cache-control field to 3600 (https://github.com/supabase/storage-js/blob/main/src/lib/StorageFileApi.ts#L15). The API should take this field and set that as max-age (https://github.com/supabase/storage-api/blob/master/src/routes/object/createObject.ts#L59). If this value is not present, it is set to no-cache.
When I upload an object to a bucket, I can see that cache-control is set in the request (see screenshot below). This should mean that the server should respond with cache-control
header value set tomax-age=3600
when I request for the object later on.
However, when I download the object afterward, the header is set to no-cache.
This is not desirable behavior, as we want to cache as many things as possible for a good user experience (and probably also lessen the load for Supabase too).
To Reproduce
- Using the supabase client, upload any object, with or without an optional
cacheControl
value set. - Download the object using the supabase client, refresh the page after the download finishes.
- on refresh, check the network tab to see that (1) the browser requested and downloaded the object again (2) and the response has
no-cache
header set.
Expected behavior
Supabase API sets cache-control headers that we pass in.
Screenshots
If applicable, add screenshots to help explain your problem.
System information
- OS: Windows
- Browser (if applies): chrome
- Version of supabase-js: “1.7.7”,
- Version of Node.js: v12.0.0
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (3 by maintainers)
Can you try with supabase-js 1.11.14 James?
It’s working! Thanks for a quick update! Looks like I was completely off the mark with https://github.com/supabase/storage-api/issues/18#issuecomment-843717897😅