You are talking about this sort of thing?

https://datatracker.ietf.org/doc/html/rfc5005

Http might be better in 2025 than it used to be but historically the cache is as much a problem as it is a solution. That is, when you have heisenbugs the answers are frequently "clear the cache" [1] and "don't use the cache" [2] and it's often a better strategy to "rip and archive the whole site right now and come back in six months and make a fresh rip" if you're working on a large scale and can tolerate being up to six months out of date.

In general database-backed sites struggle to implement if-modified-since since a fully correct implementation has to traverse the graph of all database objects that are looked up in the request which costs about as much as… the request. Your cache needs a cache and you can make it work at the system level if you have a modified date cache and always invalidate it properly. If you are doing that you might as well materialize a static web site fronting your site the way the Wordpress supercache works —- then you’ll find your site crashing a lot less!

I’ll admit ActivityPub is complex but http caching is complex in a particularly poisonous way in that there are so many alternate paths. An ActivityPub system (client+server) could be 100% correct but an http-based system might not have a clear line around it and might never be quite right. A stateless system could run for 10 years without trouble, it might take you 10 years to realize a stateful system was feeding you corrupted data.

[1] fix it... for now

[2] ... and they're no longer part of your life

> In general database-backed sites struggle to implement if-modified-since since a fully correct implementation has to traverse the graph of all database objects that are looked up in the request which costs about as much as… the request.

That's only true if your implementation favors editing performance over GET request performance ... in which case you get what you ordered. If your feed requires any database connections then that's a choice you made.

I disagree that HTTP caching is complex. The basic primitive are:

- An indication until when the returned document can be used without checking for updates.

- A way to check if a cached document is still valid (based on either modification time or id).

This provides everything you need to implement an efficient feed reader.