Use case
As it is based on Symfony 2, eZ Platform uses HTTP cache extended with features like content awareness. However, this cache management is only available for anonymous users due to HTTP restrictions.
It is of course possible to make HTTP cache vary thanks to the Vary response header, but this header can only be based on one of the request headers (e.g. Accept-Encoding). Thus, to make the cache vary on a specific context (for example a hash based on a user roles and limitations), this context must be present in the original request.
Feature
As the response can vary on a request header, the base solution is to make the kernel do a sub-request in order to retrieve the user context hash (aka user hash). Once the user hash has been retrieved, it's injected in the original request in the X-User-Hash custom header, making it possible to vary the HTTP response on this header:
This solution is implemented in Symfony reverse proxy (aka HttpCache) and is also accessible to dedicated reverse proxies like Varnish.
Note that sharing ESIs across SiteAccesses is not possible by design (see
EZP-22535
-
Cached ESI can not be shared across pages/siteaccesses due to "pathinfo" property
Closed
for technical details)
Vary by User
In cases where you need to deliver content uniquely to a given user, and tricks like using JavaScript and cookie values, hinclude, or disabling cache is not an option. Then remaining option is to vary response by cookie:
Unfortunately this is not optimal as it will by default vary by all cookies, including those set by add trackers, analytics tools, recommendation services, etc. However, as long as your application backend does not need these cookies, you can solve this by stripping everything but the session cookie. Example for Varnish can be found in the default VCL examples in part dealing with User Hash, for single-server setup this can easily be accomplished in Apache / Nginx as well.
HTTP cache clear
As eZ Platform uses FOSHttpCacheBundle, this impacts the following features:
- HTTP cache purge
- User context hash
Varnish proxy client from FOSHttpCache lib is used for clearing eZ HTTP cache, even when using Symfony HttpCache. A single BAN request is sent to registered purge servers, containing a X-Location-Id header. This header contains all Location IDs for which objects in cache need to be cleared.
Symfony reverse proxy
Symfony reverse proxy (aka HttpCache) is supported out of the box, all you have to do is to activate it.
Varnish
User context hash
FOSHttpCacheBundle User Context feature is activated by default.
As the response can vary on a request header, the base solution is to make the kernel do a sub-request in order to retrieve the context (aka user context hash). Once the user hash has been retrieved, it's injected in the original request in the X-User-Hash header, making it possible to vary the HTTP response on this header:
**X-User-Hash**.
This solution is implemented in Symfony reverse proxy (aka HttpCache) and is also accessible to dedicated reverse proxies like Varnish.
Workflow
User hash generation
eZ Platform already interferes with the hash generation process by adding current user permissions and limitations. You can also interfere in this process by implementing custom context provider(s).
User hash generation with Varnish 3
The behavior described here comes out of the box with Symfony reverse proxy, but it's of course possible to use Varnish to achieve the same.
User hash generation with Varnish 4
Default options for FOSHttpCacheBundle defined in eZ
The following configuration is defined in eZ by default for FOSHttpCacheBundle. You may override these settings.
Credits
This feature is based on Context aware HTTP caching post by asm89.