Symfony HTTP Cache / Tag Invalidation

[dantleech]

Currently this library contains several classes related to extending the Symfony HTTP Cache by way of an EventDispatchingKernel trait.

There is a general need to implement tag invalidation with the Symfony HTTP cache, and this has been done here.

Most of the logic in that package is concerned with tags and @magnusnordlander is proposing to create a new package which is dedicated to tag storage. Therefore the amount code required for adding the tagging functionality to the HTTP cache is not very large.

We could therefore reasonably add the tagging functionality in this package, however I am not so sure that it belongs here -

• I believe all of the functionality we add to the Symfony HTTP Cache can be used without the infrastructure of the FOSHttpCache.
• I think this bundle should integrate with third-party caches and not provide solutions itself.

I therefore propose to create a new package containing to the Symfony HTTP cache and ultimately remove the SymfonyCache namespace from this package.

wdyt?

[dantleech]

/cc @dbu @ddeboer @magnusnordlander @andrerom

[dbu]

i think this is the right direction to go.

so we would create a package for the event handling http cache without implementations?
and one for HttpCache tags? there are a couple of other events besides tags, like purge and refresh. where would those fit?

[andrerom]

Fine with me as long as it remains transparent for users:

• responses needs to be the same, standardized tagging header (& user context header, but digress)
• ProxyClient API needs to be same across Sf, Varnsih, Akamai .. (purge/refresh/expire/expireByTag)

[dantleech]

so we would create a package for the event handling http cache without implementations?

I was thinking more of a single HTTPCache package with all of the features that we provide here, including the forthcoming tagging. I would think that would be easier to maintain and document etc - otherwise we should consider a new organization and have separate packages for each feature, but I don't personally think that its worth it.

responses needs to be the same, standardized tagging header

Yeah, see no reason why we would change that.

ProxyClient API needs to be same across Sf, Varnsih, Akamai

I imagine the ProxyClient would staying here and the proposed package would be just another third-party that we integrate with.

[dbu]

i don't think we should micro-split features i think. the only question for me is if we want to split the event emitting trait out into a separate library. but on the other hand we can still do that when people ask for it and keep things simple for now.

we could add this in the organization that @magnusnordlander created, maybe?

[dantleech]

Do you mean the php-tag-store organization? not sure that is the most appropriate, I would think about it being in FOS. It is directly related to a symfony component after all.

[dbu]

Do you mean the |php-tag-store| organization? not sure that is the most appropriate, I think about it being in FOS. It is actually directly related to a symfony component after all.

hm, true that. what name do you propose?

[dantleech]

Maybe one of:

• FOSSymfonyHttpCache
• FOSHttpKernelCache

We could maybe suffix it with Extensions or Extra, but equally the name could be a reference to the EventDispatchingKernel itself, whereby it would make sense without a suffix.

[dbu]

while |FOSSymfonyHttpCache| is a bit hard to type with tripple S, i think its the semantically correct name. lets try that. do you want to create the issue to request permission to create this repo? the procedure is to create an issue at https://github.com/FriendsOfSymfony/friendsofsymfony.github.com/issues and describe what you want to do. maybe you can summarize the discussion from this thread so people don't need to read up the whole discussion to decide...

[dantleech]

Done: FriendsOfSymfony/friendsofsymfony.github.io#57

[dbu]

symfony 3.2 will have cache tagging built into the cache component: symfony/symfony#19047

maybe we could provide a StoreInterface implementation that uses the cache adapter and extracts tags from the response. and an additional method to invalidate tags. that would keep the effort to support tags relatively small and would probably fit into this library.

[andrerom]

I have been thinking in similar direction latly, that we probably need to simplify the 2.0 efforts a bit to unblock it, by taking advantage of Symfony Cache Component as of 3.2, and on Varnish side we can improve what we have by adding support for xkey.

[dbu]

i talked with magnus and he said he won't have time soon to contribute his refactoring ideas. so indeed we should wrap up what we have and get a version out. tagging with HttpCache could also be 2.1, it should not need a BC break.

xkey sounds cool. by default, i don't want us to force the users to install an extension. but if i see it correctly, this can be supported purely by documentation. the tagging works exactly the same as usually, just configure the tag header to xkey. invalidating means that the vcl would need to detect if the ban request has tags and then call the xkey function instead of doing a ban. did you play with it? can you contribute a documentation section for it?

[andrerom]

invalidating means that the vcl would need to detect if the ban request has tags and then call the xkey function instead of doing a ban.

Or we would need to support this in Varnsih->invalidateTags() (or extended Varnish client) where it is doing a ban which does all sorts of magic on the tags making it tedius in the vcl to undo that.

Open question is if it supports soft purging several tags at once, does not look like it, but maybe there is a way.

did you play with it?

no

[dbu]

ah right, it transforms the list of tags into a regular expression. then yes, it should be a different variant of the client. actually this is a different topic than this issue. best track it in a separate github issue.