[HttpKernel] Extending the Request class #29059

andreaslarssen · 2018-11-02T08:26:43Z

I'm on symfony/framework-bundle 4.1.6 which requires symfony/http-kernel ^4.1 (and symfony/http-foundation ^4.1).

I wanted to extend the Symfony\Component\HttpFoundation\Request class, and started googling it, and found very little on the subject. I started reading the docs, and on the http-kernel page, there's a gray info box on getting the controller arguments (...in the symfony framework). The second bullet in the box reads:

"2. If the argument in the controller is type-hinted with Symfony's Request object, the Request is passed in as the value. If you have a custom Request class, it will be injected as long as you extend the Symfony Request."

So I created a custom Request class, extending the HttpFoundation Request class:

namespace App\Requests;

use Symfony\Component\HttpFoundation\Request;

class MyCustomRequest extends Request {}

I injected the new custom Request into my controller:

namespace App\Controller;

use App\Requests\MyCustomRequest;

public function postSomething(MyCustomRequest $request) {

}

Then my app crashed, saying that:

Argument 1 passed to App\Controller\MyController::postSomething() must be an instance of App\Requests\MyCustomRequest, instance of Symfony\Component\HttpFoundation\Request given, called in /var/www/symfony/vendor/symfony/http-kernel/HttpKernel.php on line 149.

I debugged my way to the RequestValueResolver class:

namespace Symfony\Component\HttpKernel\Controller\ArgumentResolver;

final class RequestValueResolver implements ArgumentValueResolverInterface
{
    /**
     * {@inheritdoc}
     */
    public function supports(Request $request, ArgumentMetadata $argument)
    {
        return Request::class === $argument->getType() || is_subclass_of($argument->getType(), Request::class);
    }

    /**
     * {@inheritdoc}
     */
    public function resolve(Request $request, ArgumentMetadata $argument)
    {
        yield $request;
    }
}

...and when the request hits the supports method, the argument type is MyCustomRequest class, the $request is the HttpFoundation\Request, and the is_subclass_of test returns true.

When the request hits the resolve method, the argument type is still MyCustomRequest, the $request is still the HttpFoundation\Request, but the method returns (yields) the HttpFoundation\Request, which ends up injecting the HttpFoundation\Request class, and not MyCustomRequest, into my controller.

For now, I've added a custom RequestValueResolver, and changed it to this:

class RequestValueResolver implements ArgumentValueResolverInterface {
  /**
   * {@inheritdoc}
   */
  public function supports(Request $request, ArgumentMetadata $argument) {
      return is_subclass_of($argument->getType(), Request::class);
   }

  /**
   * {@inheritdoc}
   */
  public function resolve(Request $request, ArgumentMetadata $argument) {
    $requestClass = $argument->getType();

    yield forward_static_call([$requestClass, 'createFromGlobals']);
  }
}

...which injects the correct Request class. Is it the right thing to do? No idea.

If I'm reading the docs or the code wrong, or if there's another way to do this, let me know. If not, this just might be a surprising bug as noone have reported it yet.

The text was updated successfully, but these errors were encountered:

ro0NL · 2018-11-02T10:17:26Z

As you've discovered, the request is already determined at this point. I wouldnt change the request type here / ignore the current instance.. only to end up with 2 type of request instances.

Shouldnt you init the custom request type at the root of bootstrapping, thus in the front controller: https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/4.2/public/index.php#L36

Then everything is OK no?

andreaslarssen · 2018-11-02T11:01:51Z

I might have misunderstood this completely, and confused the request value resolver with the actual request on the request stack.

I think I'll use the paramconverter and turn the request content into a entity instead.

But just out of curiosity; If one would like to dynamically override the Request class, how would one do that? Use the event cycle to swap the request? Or should you just never override it?

Editing index.php (a framework specific file) don't seem like a good idea

nicolas-grekas · 2018-11-02T11:03:29Z

Editing index.php (a framework specific file) don't seem like a good idea

Yes it is! This file is yours, it doesn't belong to the framework!

andreaslarssen · 2018-11-02T11:07:18Z

@nicolas-grekas: Thinking of it, true.

So that's the idea then. You can override the Request globally and then make use of it in index.php, but there's no way of dynamically resolving and swapping a custom request class on the stack, cause that's a bad idea (?). And to validate a request (that's what I'm trying to do), use paramconverter to convert the request content to an entity?

fabpot · 2018-11-02T11:17:59Z

Be careful that overriding Request is not something we want to support. If you want to do it, don't forget to call Request::setFactory as Symfony might create Request instances for some features.

andreaslarssen · 2018-11-02T11:29:09Z

Thanks for the clarification.
I now use paramconverter to achieve what I wanted.

But if you're not supposed to extend the Request class, can I ask why the docs are saying:

"2. If the argument in the controller is type-hinted with Symfony's Request object, the Request is passed in as the value. If you have a custom Request class, it will be injected as long as you extend the Symfony Request."

And also why the RequestValueResolver checks for subclass of the Request?

fabpot · 2018-11-02T12:11:08Z

The docs should be updated; "If you have a custom Request class, it will be injected as long as you extend the Symfony Request." should be removed. @andreaslarssen Can you submit a PR on symfony/symfony-docs?

RequestValueResolver checks for a subclass to keep BC.

But in any case, even if we don't recommend extending the Request, we don't want to make it impossible.

andreaslarssen · 2018-11-02T12:24:46Z

Makes sense. I'll submit a PR. Thanks.

Extending the Request class is not recommended: symfony/symfony#29059

…arssen) This PR was submitted for the 4.1 branch but it was merged into the 3.4 branch instead (closes #10628). Discussion ---------- RM: Sentence about extending the Request class Extending the Request class is not recommended: symfony/symfony#29059 Commits ------- a23feff RM: Sentence about extending the Request class

HongKilDong · 2021-12-19T11:33:36Z

But in any case, even if we don't recommend extending the Request, we don't want to make it impossible.

Nevertheless it was done in Symfony 5.4, where \Symfony\Component\HttpFoundation\Request is hardcoded https://github.com/symfony/runtime/blob/f7a8403ae0e6847e56881c3c106e4ea2ec4ef8c9/SymfonyRuntime.php#L123

nicolas-grekas · 2021-12-19T12:00:16Z

Symfony runtime is designed for extensibility. It is possible to override this logic.

HongKilDong · 2021-12-19T12:25:53Z

Symfony runtime is designed for extensibility. It is possible to override this logic.

Ok, I got it, I just need to create own Runtime which overrides SymfonyRuntime or GenericRuntime

andreaslarssen closed this as completed Nov 2, 2018

andreaslarssen mentioned this issue Nov 2, 2018

RM: Sentence about extending the Request class symfony/symfony-docs#10628

Closed

javiereguiluz pushed a commit to symfony/symfony-docs that referenced this issue Nov 5, 2018

RM: Sentence about extending the Request class

a23feff

Extending the Request class is not recommended: symfony/symfony#29059

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

[HttpKernel] Extending the Request class #29059

[HttpKernel] Extending the Request class #29059

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

[HttpKernel] Extending the Request class #29059

[HttpKernel] Extending the Request class #29059

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!