Description
Symfony version(s) affected
6.4.0-current
Description
With #52047 the behaviour of the HttpKernelRunner
was adjusted, to not "close" the response before the KernelEvents::Terminate
-event when in debug mode. It is therefore possible to write to both the response-content and -headers during/after the execution of KernelEvents::Terminate
event-listeners when in debug mode.
While the need for a good debugging experience of code that is running during termination is valid, this does not suffice, in my opinion, to fundamentally break the behaviour of the HTTP stack when compared to a production environment.
As the response content has already been written to at this point, writing to it again will corrupt any response content, see below for a sanitized example. I have also attached an example of how this leads to differing reporting of, for example, HTTP status codes between the browser console and the symfony profiler.
How to reproduce
Following the contributors guide i have created a minimal reproduction: https://github.com/Benedikt-Brunner/Symfony_Write_After_Terminate_Reproduction
Possible Solution
As mentioned above i understand the need to debug code running in response to the Terminate event. I would still suggest disallowing writes to the response during/after the KernelEvents::Terminate
-event, as this is the behaviour described in the documentation and should not be different in debug mode (See: https://symfony.com/doc/current/components/http_kernel.html#component-http-kernel-kernel-terminate).
Additional Context
Corrupted payload example:
# Written before KernelEvents::Terminate
{
"SOME_ORIGINAL_PAYLOAD": "As there are two top level objects in this response, it is not valid JSON"
}
# Written during error handling of error in KernelEvents::Terminate
{
"errors": [
{
"status": "400",
"code": "SOME_ERROR_CODE",
"title": "Bad Request",
"detail": "Some error message",
"meta": {
"parameters": []
}
}
]
}