@@ -356,35 +356,27 @@ different cache strategies for specific parts of your page.
356356HTTP Caching and User Sessions
357357------------------------------
358358
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.
388380
389381Summary
390382-------