-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[HttpFoundation] unset Request
properties within initialize()
will cause issue on any extended Request implementing __isset()
and __get()
#51792
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Request
properties within initialise()
will cause issue on any extended Request implementing __isset()
and __get()
Request
properties within initialize()
will cause issue on any extended Request implementing __isset()
and __get()
Please send a PR. |
The unset variable is there to lazy-load that variable on reading. Making that nullable will actually break things entirely because the lazy-loading won't happen. |
The child class needs to properly call the parent methods for |
But wouldn't that expose Symfony's Request protected properties within child Request via For example: $symfonyRequest = Request::create();
$laravelRequest = LaravelRequest::create();
$symfonyRequest->baseUrl // is not possible since it's protected property.
$laravelRequest->baseUrl // is possible since it's accessed via `__get()` |
hmm, looking at those, it seems like those properties are not actually lazy-loaded on reads on them. @nicolas-grekas I think unsetting them (in #51121) instead of making them nullable was a mistake given that in 6.4, a child class would see them as |
Should be fixed by #51812 |
Thanks for the swift response/action here all! 🙂 |
Submit an additional PR: #51887 Failing Tests: |
…crynobone) This PR was merged into the 6.4 branch. Discussion ---------- [HttpFoundation] Fix type of properties in Request class | Q | A | ------------- | --- | Branch? | 6.4 | Bug fix? | yes | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | Fix #51792 <!-- prefix each issue number with "Fix #", no need to create an issue if none exists, explain below instead --> | License | MIT Additional fixes to #51812 `static::$formats` can be `null` to allow lazy-loading: https://github.com/symfony/symfony/blob/33fedcee2814947c59df2570952f8c800dfdb23e/src/Symfony/Component/HttpFoundation/Request.php#L1252-L1254 <!-- Replace this notice by a description of your feature/bugfix. This will help reviewers and should be a good start for the documentation. Additionally (see https://symfony.com/releases): - Always add tests and ensure they pass. - Bug fixes must be submitted against the lowest maintained branch where they apply (lowest branches are regularly merged to upper ones so they get the fixes too). - Features and deprecations must be submitted against the latest branch. - For new features, provide some code snippets to help understand usage. - Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry - Never break backward compatibility (see https://symfony.com/bc). --> Commits ------- 136044e [HttpFoundation] Fix type of properties in Request class
Symfony version(s) affected
7.0.0
Description
Laravel Framework is preparing support for Symfony 7 for the upcoming Laravel 11 (target release Q1 2024) and based on our existing tests the usage such as
protected string $baseUrl
and usingunset($this->baseUrl)
will cause issues forIlluminate\Http\Request
as this class extendsSymfony\Component\HttpFoundation\Request
and also implements__isset()
and__get()
.How to reproduce
The issue can be seen via our GitHub Actions: https://github.com/laravel/framework/actions/runs/6361912914/job/17276631512
To make it easier to understand, here is a simplified version of the usage:
Possible Solution
One possible solution is to opt for the following:
and set to null instead of unset.
Additional Context
Without the above change, any extended Request class similar to Laravel would need to look into exposing Symfony Request via
__isset()
and__get()
which might not be ideal.The text was updated successfully, but these errors were encountered: