Skip to content

Commit ecb0ac4

Browse files
Minor reword to make it more concise
1 parent 9b37b0e commit ecb0ac4

File tree

1 file changed

+21
-29
lines changed

1 file changed

+21
-29
lines changed

http_cache.rst

Lines changed: 21 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -356,35 +356,27 @@ different cache strategies for specific parts of your page.
356356
HTTP 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

389381
Summary
390382
-------

0 commit comments

Comments
 (0)