Custom Cache-Control response header for `/_next/image`

[jerrygreen]

Bug report

Describe the bug

When requesting /_next/image(.*), I'm getting this Response header:

Cache-Control: public, max-age=60

And it's fine... What's not fine is that I'm getting the same exact Response headers even when I use custom headers in next.config.js, i.e.:

module.exports = {
  async headers() {
    return [
      {
        // This works, and returns appropriate Response headers:
        source: '/(.*).jpg',
        headers: [
          {
            key: 'Cache-Control',
            value:
              'public, max-age=180, s-maxage=180, stale-while-revalidate=180',
          },
        ],
      },
      {
        // This doesn't work for 'Cache-Control' key (works for others though):
        source: '/_next/image(.*)',
        headers: [
          {
            key: 'Cache-Control',
            // Instead of this value:
            value: 'public, max-age=180, s-maxage=180, stale-while-revalidate=180',
            // Cache-Control response header is `public, max-age=60` in production
            // and `public, max-age=0, must-revalidate` in development
          },
        ],
      },
    ]
  },
}

To Reproduce

Try this next.config.js above, with an image that uses common <img> tag like this:

<img src="/YOUR_IMAGE_IN_PUBLIC_FOLDER.jpg">

And another tag that uses the new next/image component, with the same or whatever image url, for example:

<Image src="/YOUR_IMAGE_IN_PUBLIC_FOLDER.jpg">

And try requesting those images in the browser, and look into Devtools -> Network tab, the Response headers, and see that for common <img> tag it's actually changed, whereas for new <Image> component it is not.

Expected behavior

For /_next/image(.*) urls, I expected to see Headers that I setup, i.e. Cache-Control: public, max-age=180, s-maxage=180, stale-while-revalidate=180.

Screenshots

Common <img>:

New <Image>:

System information

• OS: not applicable / any
• Browser (if applies): not applicable / any
• Version of Next.js: 10.0.3
• Version of Node.js: 12.18.0
• Deployment: both next start on development machine, and actual Vercel deployment (screenshots demonstrate the case with local machine, but I've confirmed that the same is happening on a Vercel deployment)

Additional context

Originally I created an issue using "Feature request" template, and it got translated into "Idea discussion": #19896 (how to delete/close it pls? doesn't seem to be possible), - initially I wasn't sure if it's even possible to setup custom headers, and how that supposed to work, though I just needed that functionality. But later, upon discovering that there's such a functionality already, I figured out that actually /_next/image overrides both custom headers in next.config.js and headers property of Vercel config, i.e. it's not just some idea of a feature that is "not implemented", but it's actual bug.

[mehmetpekcan]

Are there any update here?

[aresrioja10]

Any updates? Lighthouse is lowering my score because I must serve the images with a more efficient cache policy

[guilehm]

I had to rollback to next 10.0.1, since this problem does not happen in that version.
I cannot serve my images with max-age=0.

[alexbrazier]

Looks like it was broken here https://github.com/vercel/next.js/pull/18986/files#diff-0a3c67e4ce009de800755e5b9944391b6747a989e4e3ec31586cfbf42f203bb4R305 and here https://github.com/vercel/next.js/pull/18986/files#diff-0a3c67e4ce009de800755e5b9944391b6747a989e4e3ec31586cfbf42f203bb4R152 in #18986

[PaulSenon]

Hi, I think I just had the same problem... And I found a solution to it.

TL;DR: just set the cache-control header from your provided images, pointed by the url param in /_next/image?url=....

Context:

• I'm using Vercel hosting with default CDN, and Next@10.0.4
• I'm hosting my images on a public S3 bucket
• I use the nextJs <Image/> component with url pointing on my S3 so it construct the /_next/image?url=... for me
• The cache-control max-age is always 60 whatever I write in my next.config.js or vercel.json files...

I tried:

• Setting cache-control header through next.config.js
• Setting cache-control header through vercel.json
• Rollbacking to next 10.0.1 as suggested above and testing again the two previous points.

=> But still have the issue. I cannot control the cache of /_next/image (works just well on any other routes)

After diving a bit more into that, I found somewhere in the Vercel documentation where they clearly explain why it behaves like this, and therefore I suppose it is not a bug.

It says:

If no max-age value is provided in a Cache-Control header returned by the image URL/path, a default max-age of 60 seconds is set. In turn, source images will be retrieved again and optimized on incoming requests if more than 60 seconds have passed since the last optimization of that image (in the same Edge Network node).

So I just gave it a try, by setting the cache-control header directly on my files hosted on my S3 bucket. I first seen no changes and I thought "oh well... It is definitively bugged..." but like 20min later, when I was into something else, I just found that it actually worked !!!! it just take time to get the CDN aware of your changes on the original resource. I don't understand why, because the default TTL must be 60sec, but anyway... It works.

So I hope it helps, tell me if your issue wasn't exactly this, but I'm sure it will help someone one day so I posted this here.
It took me half a day to get it to work but I've learned plenty of stuff on browser and CDN caching. Let's say it was worth the cost of the fight :)

[aresrioja10]

Hi @PaulSenon !

I'm gonna try your solution right now. I'm hosting my images in Wordpress so I've added this code into my .htaccess:

<IfModule mod_headers.c>
  <FilesMatch "\.(jpg|png|svg)">
    Header set Cache-Control "max-age=604800, public"
  </FilesMatch>
</IfModule>

[aresrioja10]

@PaulSenon It works! 🎉