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 #26643 Fix that ESI/SSI processing can turn a "private" response "public" (mpdude)
This PR was squashed before being merged into the 2.7 branch (closes#26643).
Discussion
----------
Fix that ESI/SSI processing can turn a "private" response "public"
| 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 |
Under the condition that
* we are merging in at least one *embedded* response,
* all *embedded* responses are `public`,
* the *main* response is `private` and
* all responses use expiration-based caching (note: no `s-maxage` on the *main* response)
... the resulting response will turn to `Cache-Control: public`.
The real issue is that when all responses use expiration-based caching, a combined max age is computed. This is set on the *main* response using `Response::setSharedMaxAge()`, which implicitly sets `Cache-Control: public`.
The fix provided in this PR solves the problem by applying the same logic to the *main* response that is applied for *embedded* responses, namely that responses with `!Response::isCacheable()` will make the resulting response have `Cache-Control: private, no-cache, must-revalidate` and have `(s)max-age` removed.
This makes the change easy to understand, but makes responses uncacheable too often. This is because the `Response::isCacheable()` method was written to determine whether it is safe for a shared cache to keep the response, which is not the case as soon as a `private` response is involved. This might be improved upon in another PR.
Commits
-------
3d27b59 Fix that ESI/SSI processing can turn a \"private\" response \"public\"
0 commit comments