Added a case for banning user context hash object. Partial fix for #482

[ranjzith]

This is a partial fix for banning user context hash objects from Varnish server, with out setting the right header (X-Content-Type) this would still ban all the cached content for the specified user identifier header (session id) instead of just the user context hash object. To ban only the hash response, we can either change the case in ban VCL to ban accept header or the PHP code to set the X-Content-Type header.

[dbu]

This seems indeed a good solution for FriendsOfSymfony/FOSHttpCacheBundle#482 - we will have the cookie available on responses to the hash lookup, and we specifically invalidate the request that has that cookie. as you otherwise do not copy the cookie onto the response, we will not remove any cached content requests. (banning happens on the response, never on request properties)

@lolautruche may i ask for your input on this one? am i missing something or is this the correct fix? for context, in FriendsOfSymfony/FOSHttpCacheBundle#482 @ranjzith found that we invalidate all of varnish when logging out, because the invalidation request is built on wrong assumptions.

[lolautruche]

Hi

Looks legit to me, even thought I'd have preferred to fix this in the PHP code.

[dbu]

thanks lolautruche

even thought I'd have preferred to fix this in the PHP code.

i think we can't fix this solely in the PHP code, because we do need the cookie in the response so that we can ban the specific hash lookup request. i can't think of a good way to make this more generic or otherwise less locked with the backend. we could copy the cookie of other requests to the response too, but that would feel odd to me and i don't see value in it.

[lolautruche]

Alright then 😃

👍

[dbu]

we are having a discussion in #403 that it would be much better to use a tag for the hash lookup response and then use tag invalidation. that would allow to use the feature with the symfony HttpCache and with the fastly CDN. even with varnish, when using xkey for tagging it would be much better than the current BAN based idea.

if we do that, we do not need to change anything in the VCL, which is another plus.

wdyt @ranjzith , does that make sense and would it fix your issue?

[ranjzith]

Having tag based purge/invalidation for user context hash is a nice approach and it does fix my issue #482. But I am afraid I might not be able to contribute on this here.

[dbu]

fixed in #486