Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[HttpKernel] Wrong template is rendered when configuring an exception status code #44433

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.

Sign up for GitHub

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

Jump to bottom
Closed
micheh opened this issue Dec 3, 2021 · 7 comments
Closed

[HttpKernel] Wrong template is rendered when configuring an exception status code #44433

micheh opened this issue Dec 3, 2021 · 7 comments
Labels
Bug ErrorHandler HttpKernel Status: Needs Review

Comments

@micheh
Copy link
Contributor

micheh commented Dec 3, 2021 •
edited
Loading

Symfony version(s) affected

5.4.0

Description

@lyrixx added a way to configure the status code of an exception (in #42244). When configuring the status code of an exception, the HTTP status code of the response is set as expected. However, the rendered HTML template does not seem to take the configured status code in account and Symfony will render the template as if the status code was not set.

How to reproduce

Use the config:

framework:
    exceptions:
        Doctrine\ORM\EntityNotFoundException:
            status_code: 404

Then throw an EntityNotFoundException. The HTTP status code will be 404, but the rendered template (both in the debug exception template and the production template) will show 500 Internal Server Error.

Possible Solution

Maybe the exceptions Mapping should also be used in the Symfony\Component\ErrorHandler\ErrorRenderer\HtmlErrorRenderer?

Additional Context

The status code of Symfony\Component\ErrorHandler\Exception\FlattenException::createFromThrowable is used.
@micheh micheh added the Bug label Dec 3, 2021
@lyrixx
Copy link
Member

lyrixx commented Dec 3, 2021

Thanks for the feedback. I'll have a look this weekend

aderiyenko pushed a commit to aderiyenko/symfony that referenced this issue Dec 3, 2021
fixing symfony#44433
1a95900
@aderiyenko aderiyenko mentioned this issue Dec 3, 2021
Closed
@aderiyenko
Copy link

aderiyenko commented Dec 3, 2021 •
edited
Loading

Hi @lyrixx and @micheh!

Not sure I did it correctly, but tried to fix it in here. Could you have a look if and when you have a moment?

aderiyenko pushed a commit to aderiyenko/symfony that referenced this issue Dec 3, 2021
fixing symfony#44433
e9874c4
@yceruto
Copy link
Member

yceruto commented Dec 4, 2021

We should also take care of SerializerErrorRenderer for API exceptions response body.

@yceruto
Copy link
Member

yceruto commented Dec 4, 2021 •
edited
Loading

What if we wrap the original exception (if it's mapped) into a HttpException with the mapped status code before handling the exception subrequest in ErrorListener? Thus, no change is needed on any ErrorRenderer implementation.

Otherwise, even the custom error renderers will have to worry about this exception mapping strategy on their own to fix the response body info.

@aderiyenko
Copy link

Thanks for the idea, @yceruto . Let me think of it and try to do. But not sure if I should do it as a separate PR and then we select which one to merge? Just to have both ideas side-by-side. Give me some time, I'll try to come up with something and thanks for the idea!

@GromNaN
Copy link
Member

GromNaN commented Dec 4, 2021

What if we wrap the original exception (if it's mapped) into a HttpException with the mapped status code before handling the exception subrequest in ErrorListener? Thus, no change is needed on any ErrorRenderer implementation.

@yceruto That would be a breaking change. If any ErrorRenderer uses the class of the exception, it would receive an HttpException.

Current behavior:
image

Your suggestion:
image

@yceruto
Copy link
Member

yceruto commented Dec 5, 2021 •
edited
Loading

@GromNaN Yes, that's exactly what I meant :) and I think it's fine, the exception class is debugging information, and as we can see in the 2nd screenshot the original exception is still displayed, and it will also be included in the FlattenException as the previous exception.

To be more accurate we could even create a specific HTTP exception for this mapping strategy, something like MappedHttpException? thus custom error renderers and devs will know what to do.

@nicolas-grekas nicolas-grekas mentioned this issue Dec 15, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug ErrorHandler HttpKernel Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[ErrorHandler] Render template with status code assigned to the exception aderiyenko/symfony
7 participants
@GromNaN @lyrixx @micheh @xabbuh @yceruto @carsonbot @aderiyenko