Closed
Description
Symfony version(s) affected: 3.4.x
Description
Symfony 3.4 changed behaviour of AbstractSessionListener when a session cookie is present (regardless of authentication state).
Old behaviour was to respect Cache-Control headers set on response. New behaviour introduces a B/C break that overrides Cache-Control headers in a way that cannot be easily changed. This can have a non-trivial performance impact as it prevents websites to set proper cache headers even on user-agnostic content.
A fix for this was introduced in Symfony 4.1, but no solution is easily available for Symfony 3.4.
How to reproduce
- take symfony standard edition
- add controller method that sets
Cache-Control: public, s-maxage=86400on response - load page, verify that cache header from step 2 is unmodified by Symfony
- add session cookie with random value via browser developer tools
- re-open page to see that Symfony rewrote headers to
Cache-Control: max-age=0, must-revalidate, private, s-maxage=1234
Possible Solution
One of:
- Revert the change in Symfony 3.4 - it's an undocumented B/C break in minor version (and LTS version) that is in conflict with Symfony's backwards compatibility promise.
- Backport fix from Symfony 4.1.
- Refactor logic to not rely on session cookie presence only - cookie sent by user agent might be spoofed or session may have been invalidated by backend already. A check whether user is authenticated (remembered) should be added too. This would be reasonable change to make in Symfony 4.1+ too.
Additional context
Respective code: