@@ -13,10 +13,21 @@ information), rather than individually.
13
13
14
14
.. caution ::
15
15
16
- Whenever you share caches, make sure to not output any individual content
16
+ Whenever you share caches, make sure to ** not output any individual content **
17
17
like the user name. If you have individual parts of a page, you can load
18
- those parts over AJAX requests or look into ESI _. Both approaches integrate
19
- with the concepts presented in this chapter.
18
+ those parts over AJAX requests or look into ESI _ and make the ESI sub
19
+ response vary on the cookie or completely uncached. Both approaches
20
+ integrate with the concepts presented in this chapter.
21
+
22
+ You do **not want intermediary proxies to cache responses ** that depend on the
23
+ context. If the client will not see a difference when his context changes
24
+ (e.g. is removed from or added to groups on server side), you also do not
25
+ want the clients to cache pages. Because ``VARY `` is used for the control
26
+ of the caching proxy, it is not available to control clients. Often, the
27
+ best solution is to mark your pages as private with a max-age of 0 and use
28
+ the *custom TTL * mechanism (see the documentation for
29
+ :ref: `Varnish <varnish_customttl >` or the
30
+ :ref: `Symfony HttpCache <symfonycache_customttl >`).
20
31
21
32
Overview
22
33
--------
@@ -40,6 +51,11 @@ Caching on user context works as follows:
40
51
The appropriate user role dependent representation of ``/foo.php `` will
41
52
then be returned to the client.
42
53
54
+ After this happened the first time, the hash can be cached by Varnish for this
55
+ client, moving step 2-4 into the cache. After the page is in cache, subsequent
56
+ requests from clients that got the same hash can be served from the cache as
57
+ well.
58
+
43
59
Proxy Client Configuration
44
60
--------------------------
45
61
0 commit comments