551e5ba515
This PR was squashed before being merged into the 2.7 branch (closes #23129).
Discussion
----------
Fix two edge cases in ResponseCacheStrategy
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
While reviewing how `ResponseCacheStrategy` calculates the caching-related headers for responses that embed subrequests, I came across two cases that I think are currently implemented incorrectly.
a) When the main response is public and cacheable with an expiration time, but it embeds (via ESI) a controller that does not set any caching-related headers, this embedded response is more constrained. So, the resulting (combined) response must not be cacheable, especially it may not keep the s-maxage.
b) When the main response is public and cacheable with an expiration time, but it embeds (via ESI) a controller that explicitly creates a "private" response, the resulting (combined) response must be private as well.
Commits
-------
|
||
|---|---|---|
| .. | ||
| Asset | ||
| BrowserKit | ||
| ClassLoader | ||
| Config | ||
| Console | ||
| CssSelector | ||
| Debug | ||
| DependencyInjection | ||
| DomCrawler | ||
| EventDispatcher | ||
| ExpressionLanguage | ||
| Filesystem | ||
| Finder | ||
| Form | ||
| HttpFoundation | ||
| HttpKernel | ||
| Intl | ||
| Locale | ||
| OptionsResolver | ||
| Process | ||
| PropertyAccess | ||
| Routing | ||
| Security | ||
| Serializer | ||
| Stopwatch | ||
| Templating | ||
| Translation | ||
| Validator | ||
| VarDumper | ||
| Yaml | ||