[HttpFoundation] Emit PHP warning when Response::sendHeaders() is called while output has already been sent
#60377
Conversation
|
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
There was a problem hiding this comment.
I doubt calling error_log is fine: we should use the logger infrastructure instead.
But Response is not a service, it doesn't fit.
Then, I'm wondering which service could be responsible for doing this check and logging the issue.
Maybe ErrorListener since it already has a logger injected? Any other idea?
Response::sendHeaders()
|
I guess that's a possiblity that would work: @ivo95v up to update your PR? |
|
thank you @nicolas-grekas, sending header instead of error_log is a good idea. I just update the PR |
Response::sendHeaders()Response::sendHeaders()
Response::sendHeaders()Response::sendHeaders() while output has already been sent
…output has already been sent
6359c43 to
a69cf15
Compare
Response::sendHeaders() while output has already been sentResponse::sendHeaders() is called while output has already been sent
|
Thank you @ivo95v. |
|
Hi, I think this PR now affecting stream response, it will keep on triggering "Cannot modify header information" error such as livewire/livewire#9357 |
|
Can you please open a new issue to kept he conversation there? Thanks |
Just opened #60603, thanks |
|
🤦 I'm also not able to upgrade to 7.3 because of this change. If I comment out the header function call my application works fine. There could be plenty of situations where headers have been sent on purpose at this point, so I would expect the early return of the object and not additional headers trying to be set forcing an error. Reading the initial issue, this seems extreme for an accident white space. That is not the only scenario in which headers have been sent at this point. I would instead recommend some static analysis on your project. |
|
@jase-languasco found any workaround for this issue ? |
|
@instashop-dev I'm forced to specify the version before in composer.json. I won't be able to upgrade to this version. |
…:sendHeaders()` is called while output has already been sent" (nicolas-grekas) This PR was merged into the 7.3 branch. Discussion ---------- [HttpFoundation] Revert " Emit PHP warning when `Response::sendHeaders()` is called while output has already been sent" | Q | A | ------------- | --- | Branch? | 7.3 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | Fix #60603 | License | MIT This reverts commit cf554e1, reversing changes made to 392d0c9. Let's revert as this change is too disruptive for a minor version (and I'm also going to replace this by a deprecation on 7.4 so that we can throw the warning in 8.0) Commits ------- 51985c9 Revert "minor #60377 [HttpFoundation] Emit PHP warning when `Response::sendHeaders()` is called while output has already been sent (ivo95v)"
* 7.3: Revert "minor #60377 [HttpFoundation] Emit PHP warning when `Response::sendHeaders()` is called while output has already been sent (ivo95v)" [Validator] Add missing HasNamedArguments to some constraints
* 7.4: [HttpFoundation] Deprecate using `Request::sendHeaders()` after headers have already been sent Revert "minor #60377 [HttpFoundation] Emit PHP warning when `Response::sendHeaders()` is called while output has already been sent (ivo95v)" [Validator] Add missing HasNamedArguments to some constraints [Serializer] Remove unused variable Add support for Invokable Commands in CommandTester
Description:
When Symfony attempts to send HTTP headers via the sendHeaders() method, it silently aborts if headers have already been sent (e.g., due to whitespace before the <?php tag). I spent an entire day debugging this issue and discovered that the problem was caused by an unintended whitespace before a PHP opening tag. To avoid this kind of silent failure and make future debugging easier, I decided to add an error log.