Cache-Control header not working. Why is Firefox revalidating everything?

I am using Firefox and the first page view is very fast (which is great) but upon the second viewing of the same page everything is loaded more slowly with a 304 Not Modified response on all content from the server.

304 not modified would be fine but all of my content contains a Cache-Control: public, max-age=57600 header, so after the first request for the next 16 hours all content should load from the cache without revalidating, shouldn’t it? The same thing is happening in Chrome.

What’s the point of a Cache-Control: public, max-age=57600 header if the browser is going to keep revalidating? I thought it was supposed to wait 16 hours before revalidating?

Meaning the content is in the Web browser’s cache already, and the Web browser does not have to download the needed resources again, rather would use and server one’s from it’s cache.

Okay, but how about using in combination with Expires and/or Last-Modified response HTTP header?

Do you use ony Edge Cache TTL and Browser Cache TTL options at Cloudflare or?

304 means the content was in the cache but that it was stale and revalidated. That is the part doesn’t make sense because the server responded with a Cache-Control: public, max-age=57600 header only just moments ago so the resource shouldn’t be stale for 16 more hours. This site is heavy on images so it’s important that they don’t revalidate every time the page is visited.

The exact header is actually public, max-age=57600, s-maxage=126230400 (1 year) because I’m taking advantage of Cloudflare’s cache everything page rule. There are also a last-modified and etag headers. But no Expires header. All browsers ignore the Expires header when in use in combination with cache-control: max-age=…

I fixed the problem. I had a feeling that the etag response header was the problem because I checked some other sites that didn’t have this problem and they didn’t have this header. But I was reluctant to believe it because I couldn’t find any documentation anywhere that says that etags cause the cache to become stale and it would mean rewriting some code and purging everything from the cache and I didn’t want to do that. But I did it and that fixed it.

I always knew that etags were evil!

I also removed the accept-ranges: bytes header but it’s unlikely that that was the cause. By the way I’m curious why Cloudflare doesn’t use accept-ranges in its responses. I had originally put it there because there are some large files on the site that might need to resume. But maybe that header is no longer necessary in HTTP/2 so I removed it. I couldn’t find documentation to support that but it seems like that may be.

So the problem is back. I think when I purged the cloudflare cache earlier the problem went away and I thought it was because of the adjustments I made to the headers (see above), but now I know it had nothing to do with that and more likely was related to purging the cache.

But I don’t know why. I set Cache-Control header to public, max-age=57600, s-maxage=126230400. I was under the impression that this meant that it isn’t supposed to revalidate the content until 16 hours after the content is cached by the browser but now it revalidates immediately. It’s as if somehow it knows that the content has been sitting in the Cloudflare cache for more than 16 hours. So I checked the Age header and it says 94794 which is just over a day.

So I guess max-age forces revalidation immediately if it is shorter than the Age header? If that’s so, how do I get rid of the Age header? It’s messing up my caching.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.