0

I have a page /data.txt, which is cached in the client's browser. Based on data which might be known only to the server, I now know that this page is out of date and should be refreshed. However, since it is cached, they will not re-request it for a long time (until the cache expires).

The client is now requesting a different page /foo.html. How can I make the client's browser re-request /data.txt and update its cache?

This should be done using HTTP or HTML (not all clients have JS).

(I specifically want to avoid the "cache-busting" pattern of appending version numbers to the /data.txt URL, like /data.txt?v=2. This fills the cache with useless entries rather than replacing expired ones.)

Edit for clarity: I specifically want to cache /data.txt for a long time, so telling the client not to cache it is unfortunately not what I'm looking for (for this question). I want /data.txt to be cached forever until the server chooses to invalidate it. But since the user never re-requests /data.txt, I need to invalidate it as a side effect of another request (for /foo.html).

Dragon
  • 173
  • 10
  • You may want to consider using [`IF-Modified-Since`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#if-modified-since) and `Etag` headers – Fcmam5 Jan 26 '23 at 03:38
  • @Fcmam5 Good idea! However, /data.txt is fully cached, so it won't send any requests to the server (normally), which means no If-Modified-Since header. My challenge is getting the browser to request /data.txt in the first place. – Dragon Jan 26 '23 at 04:20
  • One more question, what do you mean by `which is cached in the client's browser. Based on changes which the user has made` ? – Fcmam5 Jan 26 '23 at 17:06
  • What causes data.txt to change? – Evert Jan 26 '23 at 17:08
  • data.txt can be changed based on user actions *or* data known only to the server. Edited to clarify that. – Dragon Jan 26 '23 at 17:16
  • It looks like I can't quite do what I wanted to do here. I've accepted Fcmam5's answer as it gets closest to my original problem, but Kevin's answer was useful too. For me, I need to go through and rethink how I'm designing this. – Dragon Jan 27 '23 at 21:03

2 Answers2

1

The first step is to fix your cache headers on the data.txt resource so it uses your desired cache policy (perhaps Cache-Control: no-cache in conjunction with an ETag for conditional validation). Otherwise you're just going to have this problem over and over again.

The next step is to get clients who have it in their cache already to re-request it. In general there's no automatic way to achieve this, but if you know they're accessing foo.html then it should be possible. On that page you can make an AJAX request to data.txt with the Cache-Control: no-cache request header. That should force the browser to bypass the cache and get a fresh version, and the cache should then be repopulated with the new version.

(At least, that's how it's supposed to work. I've never tried this, and I've seen reports here that browsers don't handle Cache-Control request headers properly.)

Kevin Christopher Henry
  • 46,175
  • 7
  • 116
  • 102
  • Thank you for your answer! However, I am trying to ensure /data.txt is cached - *until* the server decides it shouldn't be anymore. I've edited the question to clarify this. – Dragon Jan 26 '23 at 17:06
  • @Dragon: I understand, and that is what I'm suggesting in the first paragraph. `no-cache` allows the client to cache the resource indefinitely, it just means that it has to check with the server (by making a conditional request) before it can use the cached value. That is the cache invalidation method offered by HTTP. – Kevin Christopher Henry Jan 26 '23 at 23:07
1

To expand my comment:

You can use IF-Modified-Since and Etag, and to invalidate the resource that has been already downloaded you may take a look at the different approaches suggested in Clear the cache in JavaScript and fetch(), how do you make a non-cached request?, most of the suggestions there mentioned fetching the resource from JavaScript with no-cache header fetch(url, {cache: "no-store"}).

Or, if you can try sending a Clear-Site-Data header if your clients' browsers are supported.

Or maybe, give up this time only for the cache-busting solution. And if it's possible for you, rename the file to something else rather than adding a querystring as suggested in Revving Filenames: don’t use querystring.

Update after clarification:

If you are not maintaining a legacy implementation with users that already have /data.txt cached, the use of Etag And IF-Modified-Since headers should help.

And for the users with the cached versions, you may redirect to: /newFile.txt or /data.txt?v=1 from /foo.html. The new requests will have the newly added headers.

Fcmam5
  • 4,888
  • 1
  • 16
  • 33