Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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\"
- Loading branch information