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
-------
3d27b5946d Fix that ESI/SSI processing can turn a \"private\" response \"public\"
This PR was merged into the 2.7 branch.
Discussion
----------
[minor] SCA: reduce repetitive method calls (sequential and in loop)
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Commits
-------
609372252f SCA: get rid of repetitive calls
This PR was squashed before being merged into the 2.7 branch (closes#25653).
Discussion
----------
PHP CS Fixer: clean up repo and adjust config
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | n/a
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Reason for this PR is that one want to have `php-cs-fixer fix -v` command executed without changes that shall not be applied for this repo. To achieve that, we need to groom config to exclude files that violate CS willingly, fix files that are violating CS unwillingly, and deliver missing case handling at PHP CS Fixer itself (https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/3359) (already merged!).
Commits
-------
b14cbc1 PHP CS Fixer: clean up repo and adjust config
