Ability to have several context hashes

[andrerom]

Recent use case popped up that we have been thinking about some years now is to add support for several context hashes. In order to allow our end users to deal with personalized responses when there is a use case to still allow it to be cached.

Context

We use X-User-Context-Hash for user permissions, and if some of our end users extend that to add additional things to the hash, lets say profile choices or other personalized user info you'll end up with:

• A lot of cache variants for ALL responses, consuming lots of additional memory
• Very low cache hit ratio

Solution

Support for several kind of hashes, each with own Vary header, so only responses that truly need to vary on e.g. X-User-Profile-Hash will actually do so (typically in addition to varying X-User-Context-Hash).

VCL would probably need to be adapted for this, unless we have a convention we can match in VCL and in PHP (SymfonyCache).

[dbu]

i agree that this could make sense. i would not want to add a lot to FOSHttpCache & Bundle for this, as its a very specific usecase and the specifics will depend on the concrete case anyways.

what i can see is a recipe in the documentation, and adding convenient extension points where needed. the thing that controls if the context header is relevant is the Vary header. one would need more control over the Vary header, i guess.

the change to the VCL is most likely replacing the hash lookup logic with VCL that also copies the other headers that the backend might Vary on. varnish can always send all those headers to the backend, as its only about triggering the vary logic that is built-in to varnish.

[andrerom]

Yes VCL will have to be adapted for this so recipe is the way to go for that, PHP wise it's specifically:

• extension point in hash logic in order to pass more then on hash in the hash lookup request
• maybe a convention like X-User-*-Hash in order to make sure we can support this in Symfony proxy given it's not so easy to extend.

[dbu]

sounds good to me! the naming convention fits into the recipe i guess?

for symfony chache proxy, we use the event system. i would think that replacing / decorating the user context listener should be feasible.

[wesnick]

I had to do this for a project. We allowed users to have the site load with a custom user theme based on a configuration setting on the user object. We then loaded different asset packages using an ESI request with a branding replay header. I can create a document outlining how we did this for the documentation, if there is interest.

[dbu]

yes, please do. together with @andrerom we can review that to get to a best practice guide for the topic 👍

[jdreesen]

@wesnick I'm definitely interested in this and would be happy about some input :)