Skip to content

Commit 9b37b0e

Browse files
committed
Documented HTTP caching and user sessions
1 parent d4dbf45 commit 9b37b0e

File tree

1 file changed

+33
-0
lines changed

1 file changed

+33
-0
lines changed

http_cache.rst

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -353,6 +353,39 @@ When pages contain dynamic parts, you may not be able to cache entire pages,
353353
but only parts of it. Read :doc:`/http_cache/esi` to find out how to configure
354354
different cache strategies for specific parts of your page.
355355

356+
HTTP Caching and User Sessions
357+
------------------------------
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');
388+
356389
Summary
357390
-------
358391

0 commit comments

Comments
 (0)