For websites that deploy using unique asset names it’s more common to bump up that max-age so that browsers won’t make a request to the server for a resource once it has it in the cache.
Is there a way to control the cache control for statics?
Someway to control generic headers for statics would be awesome.
Control over cache headers isn’t there just yet, but it might be in the works.
There’s also the possibility of using the Fly frontend as a general cache with cache headers returned by the application: First look: static asset caching - #41 by thomas - when that lands it’ll make more sense to turn off the static section and return cache (and other) headers from the application itself, and have the Fly proxy respect and pass them on.
Any updates on the 304 and cache headers support? This otherwise wonderful feature saves some backend load but does nothing to optimize the browser experience without those.
What’s the status of this PR? I’m trying to figure out the best way to serve static assets with Fly.io, but configuring NGINX or Varnish for this seems like an overkill. Statics would be awesome if it allowed us to set cache-control headers and/or respected origin’s cache-control headers.
I also would like to know the status of this feature. It makes everything a lot simpler and my app is less likely to fall over serving assets from CDN-like endpoint rather than my application server!
We’re not actively working on this now. But, our recently launched global object store may fit the bill instead. A public bucket could host and serve your statics if you can upload them yourself.
Hooking this into [statics] would take some work, but this would be easy to implement by uploading assets in your release_command with any stock s3 client. Setting cache control headers should work, and it doesn’t require that your app be deployed in multiple regions to work.
Thanks for your reply Joshua, how does my app then reference the public bucket? Maybe I can build something, alternatively just putting nginx in front of the application server is also a simple option I guess?
Putting nginx in front of your app is fine too, but that means your assets are limited to being served from where your app is deployed. Putting assets into a Tigris bucket is essentially getting the ‘global’ part of a CDN without having to use a CDN, or having to run a VM everywhere you want to serve assets closer to users.