[HttpFoundation] Allow to not pass a parameter to Request::isMethodSafe() #34167
Conversation
90e4345 to
e819256
Compare
|
Thank you @dunglas. |
…:isMethodSafe() (dunglas) This PR was squashed before being merged into the 4.3 branch. Discussion ---------- [HttpFoundation] Allow to not pass a parameter to Request::isMethodSafe() | Q | A | ------------- | --- | Branch? | 4.3 | Bug fix? | yes | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | n/a | License | MIT | Doc PR | n/a This parameter was already deprecated in Symfony 4. Allowing to not pass it in Symfony 4.3 without triggering a deprecation allows to support both HttpFoundation 4.3 and 4.4, otherwise it's not possible. Needed to make API Platform compatible with Symfony 5 (api-platform/core#3009) Commits ------- e819256 [HttpFoundation] Allow to not pass a parameter to Request::isMethodSafe()
| { | ||
| if (!\func_num_args() || func_get_arg(0)) { | ||
| // setting $andCacheable to false should be deprecated in 4.1 |
There was a problem hiding this comment.
I guess this did not happen? 🙈
There was a problem hiding this comment.
Actually, shouldn't we trigger a deprecation here, if an argument is passed? This is according to the original plan: #20603 (comment)
There was a problem hiding this comment.
Sorry, I see it's already done in 4.4: #31658
There was a problem hiding this comment.
This change seems dangerous actually. Consider this scenario:
- App was using Symfony < 3.2 (where the change was originally introduced: [HttpKernel] Deprecate checking for cacheable HTTP methods in Request::isMethodSafe() #20603)
- App contains
$request->isMethodSafe()calls which expect the old behaviour (i.e.$andCacheable = true) - Developer upgrades app to Symfony 4.3 (kind of a giant leap, but still plausible)
- The calls would return the wrong value silently after this PR
Safer alternative: In API Platform (and other bundles which need to support both Symfony 4.3 and Symfony 4.4 without triggering a deprecation), I think we should do version detection and make the call accordingly.
There was a problem hiding this comment.
This upgrade path is not supported - one must go through 3.4 and fix deprecations. We don't support another path.
There was a problem hiding this comment.
I'm trying to understand the rationale behind the double deprecation strategy, i.e.:
- Deprecate not passing the
$andCacheableargument withfalsevalue in3.2. - Throwing an error when not passing the
$andCacheableargument withfalsevalue in4.0. - Deprecate passing the
$andCacheableargument in4.14.4.
It seems to me like it's meant to prevent having unexpected behaviour when the deprecation is not caught during the upgrade process (and this can and does happen - it's impossible to catch all deprecations). And this PR seems to break the safety net afforded by this strategy.
But then again I might be overthinking this, and the double deprecation might just be out of necessity.
There was a problem hiding this comment.
The reasoning is that the deprecation is triggered in 3.4. So we can assume in 4.x that it's been taken into account.
This parameter was already deprecated in Symfony 4. Allowing to not pass it in Symfony 4.3 without triggering a deprecation allows to support both HttpFoundation 4.3 and 4.4, otherwise it's not possible.
Needed to make API Platform compatible with Symfony 5 (api-platform/core#3009)