This PR was merged into the 3.4 branch.
Discussion
----------
Address deprecation of ReflectionType::getClass()
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #36872
| License | MIT
| Doc PR | N/A
Calling `ReflectionType::getClass()` will trigger a deprecation warning on php 8. This PR switches to `getType()` if available.
Commits
-------
53b1677a4e Address deprecation of ReflectionType::getClass().
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[HttpKernel] Fix that the `Store` would not save responses with the X-Content-Digest header present
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Responses fetched from upstream sources might have a `X-Content-Digest` header, for example if the Symfony Cache is used upstream. This currently prevents the `Store` from saving such responses. In general, the value of this header should not be trusted.
As I consider this header an implementation detail of the `Store`, the fix tries to be local to that class; we should not rely on the `HttpCache` or other classes to remove untrustworthy headers for us.
This fixes the issue that when using the `HttpCache` in combination with the Symfony HttpClient, responses that have also been cached upstream in an instance of `HttpCache` are not cached locally. It adds the overhead of re-computing the content digest every time the `HttpCache` successfully re-validated a response.
Commits
-------
d8964fb8b7 [HttpKernel] Fix that the `Store` would not save responses with the X-Content-Digest header present
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpKernel][LoggerDataCollector] Prevent keys collisions in the sanitized logs processing
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/36159
| License | MIT
| Doc PR | -
`$sanitizedLogs` is used with numeric and "associative" keys. To prevent collisions when the message is a number, we can simply prepend all messages with a random letter (so we avoid a behavior refactor). It doesn't matter since they key is only used for the processing, it is dropped at the end.
Commits
-------
79fe888072 [HttpKernel][LoggerDataCollector] Prevent keys collisions in the sanitized logs processing
This PR was squashed before being merged into the 3.4 branch (closes#35305).
Discussion
----------
[HttpKernel] Fix stale-if-error behavior, add tests
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #24248
| License | MIT
| Doc PR |
This PR adds the first tests for `stale-if-error` logic in `HttpCache`.
It also fixes an observation from #24248: For responses that have been cached as `public` with an `ETag` but without a lifetime, in case of an error the stale response will be served forever (= as long as the error persists), even beyond the configured `stale-if-error` grace period.
Furthermore, it tries to improve compliance with RFC 7234: Stale responses must not be sent (under no condition) if one of
* `no-cache`
* `must-revalidate`
* `proxy-revalidate` or
* `s-maxage` (sic) is present.
This can be found in the corresponding chapters of Section 5.2.2 for these directives, but is also summarized in [Section 4.2.4](https://tools.ietf.org/html/rfc7234#section-4.2.4) as
> A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2).
Because disabling of `stale-if-error` for `s-maxage` responses probably has a big impact on the usefulness of that feature in practice, it has to be enabled explicitly with a new config setting `strict_smaxage` (defaulting to `false`).
Commits
-------
ad5f427bed [HttpKernel] Fix stale-if-error behavior, add tests
This PR was squashed before being merged into the 3.4 branch (closes#34385).
Discussion
----------
Avoid empty "If-Modified-Since" header in validation request
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Just noticed that when a response has been cached that is `public` and has an `maxAge` but does _not_ provide `Last-Modified`, the validation subrequest will have an empty `If-Modified-Since` header value.
Commits
-------
960faef66f Avoid empty \"If-Modified-Since\" header in validation request
* Added a hardcoded day 01 in order to output the proper month November
which is the correct EOL and EOM month.
* \DateTime::createFromFormat('mY') will output December for every month
where day 31 exists.
