@nicolas-grekas seeing as you mostly oversaw the changes in #25583

The problem I have with the change from #25583 is that besides what it describes it does it also does the following actions.

               ->setMaxAge(0)
               ->headers->addCacheControlDirective('must-revalidate');

In my opinion it is up to the implementation to determine if the request can be privately cached and requires revalidation.

I am curious to hear why caching is completely disallowed.

Duplicate of #26245?

Could be, but from my limited understanding I would say it is different.

This used to work. That was always broken?

No this was "broken" with session refactoring.

This is actually a duplicate of #26237, and is not a BC break, but a bugfix.

closing as a duplicate of #26237

Well this issue is a bit different than mine. (#26237)

I had the problem that i have actions which use the user and actions which do not.
If session is started all actions get no-cache headers. (which is good)

My fix was easy i separated the user needing and not needing actions within my security.yml,
so only actions which are using the user are protected by a "firewall" and start the session.

@christiaan has the problem that he wants to cache private responses, which the change breaks.
Since using max-age cache headers with cache private is within the specs and the settings gets overwritten. i say this is either a BC break or a Bug on symfonys part.

In my opinion either the listener should not touch the cache headers if already private or the headers set should be configurable. OR even both options.

Also that everything is in an abstract class does not help overwriting this any easier.
Only almost clean way i can think of is creating another listener which runs after and strips the unwanted headers out.

My fix was easy i separated the user needing and not needing actions within my security.yml,
so only actions which are using the user are protected by a "firewall" and start the session.

@smurfy could you give me more details ? Can you give me the part of the security.yml ?

Thanks !

@clement-garrigou

Well i added all routes which needs auth to the patterns.
If you have "subpaths" like /user or something can make the patterns shorter.
Hope this helps.

This way only the routes matching the firewalls pattern actually start the session.
Every other route does not and therefore do not overwrite the cache-headers.

security:
    ....
    firewalls:
        main:
            pattern: ^/(login|logout|register|resetting|change-password)
            ....

    access_control:
        - { path: ^(logout|change-password), role: IS_AUTHENTICATED_REMEMBERED}
        - { path: ^(login|register|resetting), role: IS_AUTHENTICATED_ANONYMOUSLY}

@smurfy It works, thank you very much !