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
feature #60569 [HttpKernel] Do not superseed private cache-control when no-store is set (alexander-schranz)
This PR was submitted for the 7.3 branch but it was squashed and merged into the 7.4 branch instead.
Discussion
----------
[HttpKernel] Do not superseed private cache-control when no-store is set
| Q | A
| ------------- | ---
| Branch? | 7.3
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Issues | Fix #... <!-- prefix each issue number with "Fix #", no need to create an issue if none exists, explain below instead -->
| 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