Is there a reason why non-static remote Next Images on Cloudfront have the cache-control header set to public,max-age=60,immutable? It doesn't come with any etags or last-modified either.
In comparison my local SST dev is:
public, max-age=0, must-revalidate
Vercel:
public, max-age=60, must-revalidate
Example image url:
https://{someUrl}.cloudfront.net/_next/image?url={someUrltoimage}.jpg&w=384&q=75
I know the value of 60 is default on next/image, but it drives me nuts that I can't get the usual HTTP 304 like I do with Vercel and it's causing images to be redownloaded always from Cloudfront. Is there some sort of strategy im not intuitively thinking of when dealing with immutable cache for unversioned files that may regularly change?
Hazmatyre
commented
3 months ago
Original message link
Is there a reason why non-static remote Next Images on Cloudfront have the
cache-controlheader set topublic,max-age=60,immutable? It doesn't come with any etags orlast-modifiedeither.In comparison my local SST dev is:
public, max-age=0, must-revalidateVercel:
public, max-age=60, must-revalidateExample image url:
https://{someUrl}.cloudfront.net/_next/image?url={someUrltoimage}.jpg&w=384&q=75I know the value of 60 is default on next/image, but it drives me nuts that I can't get the usual HTTP 304 like I do with Vercel and it's causing images to be redownloaded always from Cloudfront. Is there some sort of strategy im not intuitively thinking of when dealing with immutable cache for unversioned files that may regularly change?
Source code I found where it assigns
immutable? I'm on rc.11 so this might have changed. https://github.com/sst/open-next/blob/main/packages/open-next/src/adapters/image-optimization-adapter.ts