@@ -356,35 +356,27 @@ different cache strategies for specific parts of your page.
356
356
HTTP Caching and User Sessions
357
357
------------------------------
358
358
359
- When you make use of sessions, HTTP caching suddenly becomes even more
360
- complicated than it already is. When you access the session, usually that's
361
- because you want to do something for the currently visiting user only.
362
- Examples for user related content might be displaying a shopping cart,
363
- user profile information when logged in etc.
364
- This is why Symfony automatically turns all responses into non-cacheable,
365
- private responses in case a session was started during the current request.
366
- For the majority of applications this is a good default setting. You want
367
- to ensure that there is absolutely no risk of caching user related information
368
- that is then suddenly exposed to another user eventually leading to security
369
- issues.
370
-
371
- However, just because a session is started does not automatically mean you
372
- cannot cache the response. For example user group related information could
373
- be cached for all the users belonging to the same user group. And depending
374
- on how complicated and resource intensive gathering this information is, it
375
- might well be worth caching. It just simply gets very complicated, needs a
376
- lot of special handling, cache invalidation, probably matching server setups
377
- and much more. In other words: It simply goes beyond the scope of Symfony.
378
- If you do want to get into this, we recommend you checkout the `FOSHttpCacheBundle `_
379
- that provides all sort of options and extended documentation for this use case.
380
-
381
- To disable the default behaviour of Symfony turning all responses into
382
- non-cacheable, private ones if a session was started, you can add an internal
383
- header to your response and Symfony will leave it untouched::
384
-
385
- use Symfony\Component\HttpKernel\EventListener\AbstractSessionListener;
386
-
387
- $response->headers->set(AbstractSessionListener::NO_AUTO_CACHE_CONTROL_HEADER, 'true');
359
+ Whenever the session is started during a request, Symfony turns the response
360
+ into a private non-cacheable response. This is the best default behavior to not
361
+ cache private user information (e.g. a shopping cart, a user profile details,
362
+ etc.) and expose it to other visitors.
363
+
364
+ However, even requests making use of the session can be cached under some
365
+ circumstances. For example, information related to some user group could be
366
+ cached for all the users belonging to that group. Handling these advanced
367
+ caching scenarios is out of the scope of Symfony, but they can be solved with
368
+ the `FOSHttpCacheBundle `_.
369
+
370
+ In order to disable the default Symfony behavior that makes requests using the
371
+ session uncacheable, add the following internal header to your response and
372
+ Symfony won't modify it::
373
+
374
+ use Symfony\Component\HttpKernel\EventListener\AbstractSessionListener;
375
+
376
+ $response->headers->set(AbstractSessionListener::NO_AUTO_CACHE_CONTROL_HEADER, 'true');
377
+
378
+ .. versionadded :: 4.1
379
+ The ``NO_AUTO_CACHE_CONTROL_HEADER `` header was introduced in Symfony 4.1.
388
380
389
381
Summary
390
382
-------
0 commit comments