Rely on cache-control headers
woutermont opened this issue · comments
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?
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.
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.
Because the caching headers will be set to 1 day or so, or at least a couple of hours, making the problem worse.
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.