[Routing] TypeErrors in a controller route should return HTTP 400 (Invalid request) instead of 500 (Server error)

[fmonts]

I think it would make more sense if a HTTP status code 400 is returned when the type of a variable is wrong, for example:

/**
 * @Route("/{_locale}/news/{id}", name="news_show")
 */
public function show(int $id)
{
    ...
}

Which is much easier to write and remember than the annotation requirements={"id"="\d+"}

The TypeError could be caught and shown instead a 400 or 404 error.

Edit: I know an integer is not the same as a numeric string, but casting to integer has been the oldest way to protect from SQL injections since the beginning of time in PHP and I guess it's still widely used...

[Tobion]

I don't think TypeErrors should be caught here. Instead we could automatically add a regex requirement to a placeholder when the parameter has an int type.

[jkufner]

What if a Value Resolver fails to resolve the value?

What if strict types are in use?

What if the argument is boolean, float, or a date?

There are more cases and they all sould behave consistently.

I don't like adding a regexp automatically. That seems as a dirty hotfix. This matter should be solved in a more generic way.

[stof]

What if strict types are in use?

Strict types are not in use in the HttpKernel when calling the controller. We know that for sure.

What if the argument is boolean, float, or a date?

For these cases, you must need an argument resolver to perform the conversion anyway. So a 500 error when it is missing is actually right: the server code is broken.

[nicolas-grekas]

I'm 👎 here, this is going too deep into type-inference deductions.

[carsonbot]

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

[fmonts]

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

Since the big bosses said no, I'm closing it