Rely on cache-control headers

[woutermont]

Currently, the WebID issuer cache is a LRU cache with a fixed 60s maximum age. This breaks scenarios like the following: using a token from my first issuer, I add a second issuer to my profile, and immediately (<60s) request some resource using a token from that second issuer.

A first step would be to make the maximum age more easily configurable, e.g. using constructor parameters. However, I believe this would (1) only solve the problems when we then set the maximum age to zero, which obviously (2) would be bad for performance.

I would therefore propose to let go of the fixed cache in favor of a caching mechanism based on the cache-control headers sent by the servers hosting the WebID profiles. Would this be possible?

[RubenVerborgh]

a caching mechanism based on the cache-control headers sent by the servers hosting the WebID profiles.

That's not necessarily better though.

Caching is a hard problem. I think what we'd need is an option to be passed to the validator cache: false that is propagated all the way down, for scenarios that are especially time-sensitive.

[woutermont]

a caching mechanism based on the cache-control headers sent by the servers hosting the WebID profiles.

That's not necessarily better though.

Could you explain why you don't think so, @RubenVerborgh?

Of course, an option to switch of the cache is a good first step. It just would be requesting a lot of unchanged profiles.

[RubenVerborgh]

Because the caching headers will be set to 1 day or so, or at least a couple of hours, making the problem worse.

[woutermont]

But that is totally up to the server, which could then use a no-cache header or work with E-Tags, maybe only for a subset of resources, in order to achieve the optimal behavior.