Support Tags with Symfony Http cache

[andrerom]

Opening this to continue the conversation of adding such a feature.
In our (eZ) case we would like to use tags both when configured with Varnish and when using Sf Cache.

I'm not 100% up to speed on EventDispatchingHttpCache as introduced earlier this year, but possible idea as discussed with @lolautruche was to use hardlinks (see symfony/symfony#15458) to place the cache in several locations representing the tags, to be able to efficiently do reverse lookup on "banning", or to allow stale/grace cache; expiry by tag expiry. Discussed that with @lsmith77 some time ago and decided to take the discussion here.

[dbu]

a lot of brainstorming happened in #148

the problem there is that we talk about general BAN implementation, which is a lot harder than cache tagging. but imo it would make sense to refactor things so that the tag system does not automatically assume that it is using BAN. then for symfony http cache, we could indeed attach the tags to the response and handle them, without needing to build full BAN support on arbitrary headers.

the event dispatching is currently refactored to become a trait in #233 - don't change the code of the kernel class anymore at this point. i think for the actual tag invalidation, we might need another event on the kernel. or maybe the existing events are actually enough, not sure.

[andrerom]

BAN support for arbitrary headers is not something we need, so focusing more on Tags as a feature makes a lot of sense here as well. Hence the title.

Also, Ban in Varnish does not support grace, and this is a problem (causes cache dog-piling on high load), so no need to reimplement such problems in Sf Cache impl. :)

[dbu]

would you implement the tag invalidation with grace? either way. the first step would be to refactor our tag handlers to no longer require the BanInterface and introduce a new TagInterface that varnish can implement with ban but the sf httpcache can implement differently. does that make sense?

[andrerom]

would you implement the tag invalidation with grace?

Most likely not, 1. use same logic as purge, 2. adding possibility to expire cache later which can also be supported on Varnish (unsure about Nginx). 3. option for using expiry instead of purge for clearing by tag with SF Cache, 4. for Varnish such option would either need SoftBan, or that we track all url's and their tags somehow to be able to do expiry on every affected url manually. makes sense? :)

either way. the first step would be to refactor our tag handlers to no longer require the BanInterface and introduce a new TagInterface that varnish can implement with ban but the sf httpcache can implement differently. does that make sense?

yes

[dbu]

does purge have no grace? (in another context, this would be a weird question indeed) do you have time to work on the refactoring of the tag handler to be independent of banning? that would be the first step and we could merge that even without the symfony cache support. about expanding on tag invalidation & grace with varnish: not sure if its worth the effort. and it sounds horribly complicated and adding more overhead. rather hope for softban... but anyways i guess we agree on the first steps so lets see how well that works.

[andrerom]

does purge have no grace? (in another context, this would be a weird
question indeed)

Depends on the vcl in Varnish, but what is supported with Sf Cache for this?

do you have time to work on the refactoring of the tag handler to be
independent of banning?

Not right now, no.

about expanding on tag invalidation & grace with varnish: not sure if
its worth the effort. and it sounds horribly complicated and adding more
overhead. rather hope for softban...

Have tried to reach out to folks at Varnish several times, and each time they don't seems much interested in implement SoftBan, they might feel it contradicts their business model or something. So this is why I have more or less stopped expecting that to happen, and looking at alternatives, cause no grace is a showstopper for any kind of serious traffic.

[andrerom]

do you have time to work on the refactoring of the tag handler to be
independent of banning?

Have some time now, tried to have a look but didn't actually see what needs to change on tag handler, except this part:

if (!$invalidator->supports(CacheInvalidator::INVALIDATE)) {
    throw UnsupportedProxyOperationException::cacheDoesNotImplement('BAN');
}

From what I could see it is mostly CacheInvalidator that needs to be updated, and it's use like above, to introduce concept of tags so cache handlers can expose this functionality. Something in direction of:

public function invalidateTags(array $tags, $tagsHeader = 'X-Cache-Tags')
{
    if (!$this->cache instanceof TagInterface) {
        throw UnsupportedProxyOperationException::cacheDoesNotImplement('Tags');
    }
    $this->cache->tags($tags, $tagsHeader);
    return $this;
}

NB: I'm a bit torn if this should pass cache header around or not, it could also be a configuration as SfCache will perhaps ignore it, or well we can add it to the path tags are stored in so might kind of work. aka tags/x-cache-tags/<tag-value>

wdyt @dbu @ddeboer @lolautruche ?

[andrerom]

Created PR with that approach in #237