Netlify ignores cache-control for 304

Support
14

Edit: Actually, checking the page a few minutes after initial deploy, images are flickering again. For some reason, the headers settings in netlify.toml don’t seem to stick for long.

I can confirm the same issue with our demo site - currently evaluating Netlify / NetlifyCMS for our company site at https://loving-pasteur-90ee68.netlify.com/

304 responses go back to default Cache-Control, leading to noticeable flickering when navigating between pages that use the same image files.

The issue is jarring when using Firefox, less so when using Chrome.

As a workaround, I’ve added the following settings to my netlify.toml - this removes the flickering, with max-age being short enough to invalidate content quickly.

Ideally, we probably wouldn’t have to use this settings, so adding this comment for future reference and to be kept in the loop regarding updates :slight_smile:

[[headers]]
  for = "*.jpg"
  [headers.values]
    Cache-Control = "public, max-age=300"

[[headers]]
  for = "*.png"
  [headers.values]
    Cache-Control = "public, max-age=300"
1 Like
15

@MatsLanGoH, we appreciate your thoughts on this. We will update this topic if/when the behavior is corrected. Also, please feel free to “watch” this topic (there is a button below) if you want to receive emails about any updates here.

Last but not least, welcome to our community site! :slightly_smiling_face:

1 Like
16

Has this been solved? I believe this may be what is affecting me here

18

Hi, @Rangoli-Software.

I replied in the topic you linked to above. I believe the issue you are experiencing is unrelated to the 304 status issue.

The issue filed for the 304 responses not sending custom headers remains open. It is not resolved at this time. (Again, though, I don’t think it is the root cause of the issue you are seeing.)

19

A fix for this issue would be appreciated.
For development purpose, we need to totally disable cache management on server-side, but this “304” behaviour breaks our application :cry:

Our configuration:

/*
  Cache-Control: no-cache no-store must-revalidate max-age=0

Thank you

20

It is much better with , between instructions!

This is working great:

/*
  Cache-Control: no-cache, no-store, must-revalidate, max-age=0
1 Like
21

Hi, @dlecan. If/when the 304 issue is resolved, we’ll post another update here. (This issue is still open at this time.)

22

Hey @luke,
Any updates on this issue ? Could this be related behaviour I’m seeing in this thread.

23

Sorry, we don’t have an update yet. However, looking at your thread, it does look to be the same 304 issue so you’ll want to keep an eye on this thread. We’ll update this thread once we’ve resolved the issue. Thank you for your patience.

24

Has this issue been resolved yet?

I have the same caching issue on my site.

The weird thing is, there weren’t any problems with the cache-control header until a few days ago. When I checked it at least 4 days ago (right after the last build), it definitely worked.

The caching issue was discovered exactly 10 minutes ago from now.

This is my netlify.toml:

[[headers]]
  for = "/*"
  [headers.values]
    Access-Control-Allow-Origin = "*"
    cache-control = "public, max-age=3600"
26

Hey there, @salmonspace !

Thank you for sharing this with us. Unfortunately, I do not have an update or an ETA on this. As Dennis mentioned above, we will update this thread once the issue is resolved.

Thank you for your patience!

28

Hello!

Was this issue already resolved? I have the same (a similar?) issue on my site:

When reloading, the images are always refetched ignoring the cache settings, even when navigating back and forth. I have tried to change the cache headers with the netlify.toml:

[[headers]]
  for = "/images/*"

  [headers.values]
    cache-control = '''
    public,
    s-max-age=604800
    '''
29

Hi @nirazul,

The issue sadly still exists.

30

I’m interested in this issue as well, since I was troubleshooting why my cache-control headers weren’t working for over an hour; I double-checked whether I was writing my rules correctly in the Netlify Playground, I split out my glob into multiple individual sections, and I added a custom x-does-this-work="true" header on the off-chance it was a problem with cache-control specifically.

But IG it’s just that we need a method to set custom headers per response code?

Would it be possible to borrow from the redirects syntax?

ex:

[[headers]]
  for = "/*"
  status = "304"
  [headers.values]
    Cache-Control = "public, max-age=0, stale-while-revalidate"
32

Hey @jasikpark,

I’m not following what you’re trying. By looking at the toml file, it appears as if you’re trying to set a custom header only when the file is served with a 304 status. Not only this won’t work (as it’s not currently supported), I’m not sure what this will solve.

Could you elaborate?

33

This is trying to work around a bug in Netlify. According to RFC 7232 The 304 response “MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.” Netlify doesn’t do this so @jasikpark is attempting to hack around this by setting the Cache-Control header manually.

34

Oh well, in that case, like I’ve said above, it’s not currently supported and thus would not work.

35

It doesn’t make sense to support it either because the RFC says what headers should be present and that they should match the values from the 200 response. Configuring the headers differently is invalid. But it would be nice to get this bug fixed.

37

Has there been any movement on this?

I have a similar use case where I’d like to control the caching. Initial request works fine, but it seems the etag is used in requests after a refresh and then I get stuck in a 304 loop.

38

I’m sure this might be mentioned above and you would have gone through it, but this is a risky endeavour:

In any case, the issue still persists, and you can probably work around it by using a service worker to cache files.