README.md

PSR-6 compatible Symfony HttpCache Store

Introduction

Symfony's HttpCache store implementation is rather old and was developed
when there were no separate components for locking and caching yet. Moreover,
expired cache entries are never pruned and thus causes your cache directory
to continue to grow forever until you delete it manually.

Along the way, I needed support for cache invalidation based on tags which was
pretty easy to implement thanks to the Symfony Cache component.

prune_threshold: Configure the number of write actions until the store
will prune the expired cache entries. Pass 0 to disable automated pruning.

Type: intDefault: 500

cache_tags_header: The HTTP header name used to check for tags

Type: stringDefault: Cache-Tags

Cache tagging

Tag cache entries by adding a response header with the tags as a comma
separated value. By default, that header is called Cache-Tags, this can be
overwritten in cache_tags_header.

To invalidate tags, call the method Psr6Store::invalidateTags or use the
PurgeTagsListener from the FOSHttpCache library to handle tag
invalidation requests.

Pruning expired cache entries

By default, this store removes expired entries from the cache after every 500
cache write operations. Fetching data does not affect performance.
You can change the automated pruning frequency with the prune_threshold
configuration setting.

You can also manually trigger pruning by calling the prune() method on the
cache. With this, you could for example implement a cron job that loads the store
and prunes it at a configured interval, to prevent slowing down random requests
that were cache misses because they have to wait for the pruning to happen. If you
have set up a cron job, you should disable auto pruning by setting the threshold
to 0.

WARNING

It is possible to configure other cache adapters or lock stores than the
filesystem ones. Only do this if you are sure of what you are doing. In
this pull request Fabien refused to add PSR-6 store support to
the Symfony AppCache with the following arguments:

Using a filesystem allows for opcache to make the cache very
effective;

The cache contains some PHP (when using ESI for instance) and storing
PHP in anything else than a filesystem would mean eval()-ing
strings coming from Redis / Memcache /...;

HttpCache is triggered very early and does not have access to the
container or anything else really. And it should stay that way to be
efficient.

While the first and third point depend on what you do and need, be sure to
respect the second point. If you use network enabled caches like Redis or
Memcache, make sure that they are not shared with other systems to avoid code
injection!

Credits

I would like to thank David for his invaluable feedback on this library
while we were working on an integration for the awesome FOSHttpCache library.