Skip to content

Instantly share code, notes, and snippets.

@dbu
Last active February 8, 2016 12:19
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dbu/5b162a6707d8922014c9 to your computer and use it in GitHub Desktop.
Save dbu/5b162a6707d8922014c9 to your computer and use it in GitHub Desktop.
channel neutral tag handling for FOSHttpCache
<?php
/**
* Handle tagging. Both request and response are passed,
* so that tags can either be added to the response, or
* recorded with the request information.
*/
interface TagHandler
{
/**
* Remove/Expire cache objects based on cache tags
*/
public function invalidateTags(array $tags);
/**
* Record tag information.
*
* Either on the response (e.g. tags header) or out of band, linked to the
* request.
*
* @return ResponseInterface
*/
public function tagPsr(RequestInterface $request, ResponseInterface $response, array $tags);
/**
* Record tag information.
*
* Either sending a plain header, or recording the tags out of band, linked to the URL.
*/
public function tagPlain($url, array $tags);
/**
* Same as tagPsr but for symfony. in bundle only.
*/
public function tagSymfony(Request, Response, array $tags);
}
// implementation detail, not part of the interface
/**
* Get the value for the HTTP tag header.
*/
public function getTagsHeaderValue(array $tags);
/**
* Get the HTTP header name that will hold cache tags.
*/
public function getTagsHeaderName();
@dbu
Copy link
Author

dbu commented Dec 15, 2015

The concrete implementations will need the cache manager to either ban tag headers or send purge / refresh requests to all urls that where recorded for a specific tag. the in-band solution needs no additional dependencies, the cache manager supporting ban is enough. the out-of-band solution needs an additional recorder, a key => multivalue store.

@dantleech: does this also cover what you are building for the symfony HttpCache? the moment when we will record the tags is before the cache is sent out. so maybe from the perspective of the library, you would still use in band information when recording the cache entries, as you do that later in the HttpCache kernel?

with this solution, the user will need to instantiate the matching invalidator for their caching proxy: ban for varnish, symfony for HttpCache, "out-of-band" for any cache (works with varnish, nginx or symfony kernel, as long as purge/refresh is provided. should even work with akamai).

@ddeboer
Copy link

ddeboer commented Dec 15, 2015

Perhaps it would be better to split the interface:

interface ResponseTagHandler extends TagHandler
{
    public function tag(ResponseInterface $response);
}

interface OutOfBandTagHandler extends TagHandler
{
    public function tag(/*no typehint */ $recorderOrSomethingSimilar);
}

@dbu
Copy link
Author

dbu commented Feb 8, 2016

the user should not have to care about the tag implementation, whether its in band or out of band. that is why i would always pass the Request and let the tag handler decide whether to store a map of tag to response id or request url or whatever, or to put the tags into the response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment