New users should be told that they need to force-refresh pages

[michaellenaghan]

Typlog uses fairly aggressive 1 hour browser-side caching on Pages and Posts. That's not necessarily bad, but you should probably warn new users; when I first started changing settings and publishing Pages and Posts they didn't show up, even when I refreshed the browser. I eventually realized that I needed to force-refresh.

(A different and better option would be to use Etags, but maybe there's no way to do that cheaply?)

[lepture]

Actually we are using Date to invalidate edge cache. It has the same effect with Etag. The problem you are facing is caused by browser cache. Once a post is published, Typlog will purge the edge cache related to the post, such as homepage, archive page, and tag page.

However, the browser cache will not be invalidated, because it is impossible.

I can totally remove the browser level cache. (Yes, it can be removed)

[michaellenaghan]

It's been a while since I've had to think about this in detail, but I think the typical approach is something like:

• html and some other files
  • give them an Etag
  • give them a Last-Modified
  • give them a 0 time-to-live
  • give them a must-revalidate
  • give them some other things mentioned briefly below
• most other files
  • fingerprint the files
  • rename the files to include the fingerprint
  • give them a far-future time-to-live
  • etc.

The second part of that is just a "future possibility;" too much work for now, but worth keeping in mind.

If you're doing the first part (for all files), you don't actually need to invalidate the cache. The cache will always check back with the server (must-revalidate), with an If-Modified-Since header. But: but this assumes that you can quickly and cheaply compute a site's timestamp without having to generate the page, etc.

That's the quick outline, and yes, I think it would be worth doing; it would provide a much better user experience, in many ways.

Let me know if it would be worth flushing out more details. For example: there are newer caching header options that you'd also want to set that let the cache know that it can serve possibly stale content if it can't reach the origin, etc. Those kinds of things will make the system a little more robust.

[lepture]

The default Cache-Control is max-age=3600, must-revalidate now.

[michaellenaghan]

I did a quick scan to refresh my knowledge, and I believe this is correct...

Use max-age=0, must-revalidate. (That's actually the equivalent of no-cache, but most people use the longer version for historical reasons.)

With that, browsers should send If-Modified-Since, and you should be able to reply with status 304 (and the correct set of headers) if the page hasn't been modified.

As I said, all of this assumes that you can quickly and efficiently determine the correct date for each URL on the site. (Different files could use different strategies; for example, static files could use per-file modification dates.)

This is a pretty simple caching scheme. There are more advanced ones. Maybe someday.

===

Here's the other option I was talking about: stale-if-error. It allows a cache to use a stale response if the server responds with an error during re-validation. After thinking about it, I don't think it would be of much use in this scenario.

In any event, here is the MDN page on Cache-Control; you can see what you think.