You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bug #60569 [HttpKernel] Do not superseed private cache-control when no-store is set (alexander-schranz)
Discussion
----------
[HttpKernel] Do not superseed private cache-control when no-store is set
| Q | A
| ------------- | ---
| Branch? | 7.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Issues | -
| License | MIT
I don't think its a good idea to superseed the private cache control via the new noStore option
* #59301
If somebody want to set it to `private` they should explicit do it. via `#[Cache(private: true, noStore: true)]`. I would avoid this non transparent changes in general.
I had usecases in the past where the response is still public for the symfony cache and varnish public and the no store was only for the third party caches and in browser caches. This specially come into play with usage of `ESI` where the general page is cached, but no-store set to not allow back forwards caches, because of the ESI content.
/cc `@smnandre`
Commits
-------
7e6e33e [HttpKernel] Do not superseed private cache-control when no-store is set
0 commit comments