Enable custom "Cache-Control" header for remote images on next/image

[pedrosodre]

Describe the feature you'd like to request

Today, when we use next/image component to optimize an image that cames from a remote location (like AWS S3 or a CDN), next always set Cache-Control header as max-age=0, must-revalidate. I understand this behavior, but if we put a CDN on our frontend project it nevers hits CDN cache, since origin asked to revalidate it.

For that reason, would be great to be able to customize the Cache-Control header for remote images.

Describe the solution you'd like

I've checked image-optimizer code and actually we just set a high value to Cache-Control when the image is static. Would be great to be able to customize this header for remote images on next.config.js file (when image is not static).

Describe alternatives you've considered

To fix it right now with the resources we have, it was necessary to overwrite the response.setHeader method to force a new value to Cache-Control for /_next/image path, as the example below:

server.use(function (req, res, next) {
    const nextImagePath = '/_next/image';
    const cacheControlHeaderKey = 'Cache-Control';
    const cacheControlHeaderValue = 'public, max-age=31536000';

    const { setHeader } = res;

    res.setHeader = function (key, value) {
        if (req.path === nextImagePath && key === cacheControlHeaderKey) {
            value = cacheControlHeaderValue;
        }

        setHeader.call(this, key, value);
    };

    next();
});

[pedrosodre]

I opened a pull request for this feature, it's just missing an example (if needed), because I decided to wait a feedback about this feature request before get everything done.

#35596

[pedrosodre]

@balazsorban44 we already made a big thread on pull-request page. Should I resume a bit what we already told there, here on discussion page?

[pbright]

@pedrosodre Thanks for opening this discussion and the pull request, and (most especially) for the workaround. I have made a more detailed comment in the pull request. The behaviour you're asking for was (as I assume you realise) how Next worked prior to 12.1.

I'm not sure why this was changed although I assume it relates to this comment in the release blog post:
https://nextjs.org/blog/next-12-1#faster-image-optimization

[pedrosodre]

Glad to see I'm not the only one with that use case. I saw your comment and the last behavior, but I still prefer to be able to customize more the header value for remote images, since before Next 12 the header has "must-revalidate", which make CDN never returns "Hit" directly. I think the new behavior we are discussing in pull request should solve both cases =)

[aviita]

We are battling with the same issue with nextjs 13.2.3 image server. We have Azure Front Door for CDN purposes in front of the image server. We have converted all the images to have header immutable header.

Even while the images are small there is delay (and we also have usage in locations other than our main regions from which we are hosting the images, including Australia and Japan), while servers are in US and Europe.

Azure Front Door shows average cache hit ratio of only 22 % for the past 30 days although our content does not change very often and the files are truly immutable.

Front Door Byte hit ratio graphed here:

I would say this should be a very valid use case to have that one wants to serve immutable files with proper cache-control directives (although next.js versions might affect quality of the results or what ever might be the reason not allow treating these as immutable). We have our own cache busting in place with images served from immutable paths and path changing on files being updated. And if there are really valid reasons that between nextjs versions the immutability is not good, then there should be possibility to add additional cache busting with query string altered based on nextjs cached image hash or something. And this support should be built in to nextjs it self.