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

submitted by

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

#EvanPoll #poll

No votes have been cast yet.

Show voting form

View results

Total votes: 0.

Poll closes 4 months ago.

8
1

Log in to comment

Hot Top New Old

@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 🙂

 reply
3
OP

@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.

 reply
1
edited

@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.

 reply
2
OP

@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!

 reply
2
OP

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.

 reply
1
OP

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).

 reply
1
Insert image