#ActivityPub developers: which of these HTTP caching headers does your software publish or consume?

#ActivityPub developers: which of these HTTP caching headers does your software publish or consume?

#EvanPoll #poll

@evan My systems export both Etag and Last-Modified. I have no idea how the computers looking at my stuff know which to prioritise, and typically on my browser I still need to refresh the page manually to see any changes. Caching really is quite hard.

@evan@cosocial.ca all four, but only for contexts. It's how NodeBB's topic synchronization logic works, although there isn't an FEP for it yet

Cache-Control and Vary

@evan@cosocial.ca

None of them... yet...

@julian hmmm. With a reverse chron collection you can do pretty well with `totalItems` and the first item on the first page.

If there were net items added or deleted, `totalItems` will be different.

If the same number of items were added and deleted, the most recent item will be different.

So you can check synch with a couple of hits.

Thanks to everyone who replied! Unfortunately HTTP caching is not our strong suit in the ActivityPub world; HTTP Signature header(s) are a real public cache buster. But you can do at least some good caching per user. tags.pub provides ETag, and sends If-None-Match and If-Modified-Since, but doesn't do Last-Modified well yet.

The problem with Signature: and Signature-Input:

If the server wants to say, "this content is different for different users", you use the Vary header. For OAuth, you'd use Vary: Authorization, say. And the cache knows to separate data for different users. Same OAuth token, you can reuse the cached data.

We include our ID in the Signature (or Signature-Input) header. But we also include a timestamp there, so every single request has a different signature (by design).

It would probably be good if we had a separate identity header, so servers can say, "this stuff is different by user, this is the same for every user" with Vary: Signature-Key-Id or something.

@evan@cosocial.ca yes, you can but that's not the point I think?

The point is that generating the collection is more expensive than returning the ETag, if it's cached (and it is, with NodeBB).

So if I wanted to check the context for updates, I could issue a lightweight HEAD instead of a GET, and the target server could simply bounce back the ETag.

Likewise, I think it sends the appropriate http response (304 Not Modified) when If-None-Match matches the ETag, or something. So I think with collections of object ids, the savings are minimal but it could add up to much more for endpoints that return entire objects... Like an outbox!

It's been awhile since I worked on that code.

@julian ah, right! I meant, many Fediverse servers don't do a good job with caching headers, but you can use some of the data to guess if there have been changes. Caching headers are better though!