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

Skip to content

[HttpFoundation] [Runtime] Response can be written to during/after KernelEvents::Terminate-event in debug mode #59447

Closed
@Benedikt-Brunner

Description

@Benedikt-Brunner

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": []
      }
    }
  ]
}

Inconsistent HTTP status code reporting example:

Browser:
Screenshot 2025-01-09 at 09 13 59

Profiler:
Screenshot 2025-01-09 at 09 12 29

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions