headers_sent allows you to define a file and a line that has undesirable output, otherwise it is impossible to identify and correct the error, there is not enough of this and it is difficult to debug, but the edit is very small, but gives many possibilities, I hope this edit will fall into the main branch, thanks!

https://www.php.net/manual/en/function.headers-sent.php

Originally posted by @undercloud at zendframework/zend-httphandlerrunner#13

Added error listeners to RequestHandlerRunner to be able to log errors/exceptions thrown in ::run() method.
Also made emitMarshalServerRequestException public to it can be called from the outside-

Originally posted by @maurice2k at zendframework/zend-httphandlerrunner#5

Is the closure required here? Can't $serverRequestErrorResponseGenerator be assigned directly to $this->serverRequestErrorResponseGenerator?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Use matchDepNames instead of matchPackageNames

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency phpunit/phpunit to v11

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Feature Request

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• Create a .psalm.xml.dist in the project root
• Copy and paste the contents from this psalm.xml.dist
• Run $ composer require vimeo/psalm
• Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• Add a composer script static-analysis with the command psalm --shepherd --stats
• Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• Fix as many psalm errors as possible.

RFC

Goal

Allow users to use implementations of EmitterInterface without requiring laminas-httphandlerrunner be installed.

Background,

• Library authors may want to provide different implementations of EmitterInterface for different use cases.
• Implementations of EmitterInterface could be created that do not require all of laminas-httphandlerrunner.

Note: There are several forks of laminas-httphandlerrunner (See non-exhaustive list) some of which contain only a copy of EmitterInterface

Considerations

Users will have to implement the interface from PHP Contrib instead of [laminas/laminas-httphandlerrunner](https://github.com/laminas/laminas-httphandlerrunner/). Since the interface will not change, users will only need to composer require php-contrib/http-emitter or composer require laminas/http-emitter, then update the use statements in their projects.

Proposal(s)

I am proposing that EmitterInterface be moved either to PHP Contrib or to a separate project in laminas.

Appendix

List of Copies of EmitterInterface

• https://github.com/tomrf/http-emitter/blob/master/src/Interface/SapiEmitterInterface.php
• https://github.com/zaphyr-org/http-emitter/blob/master/src/Contracts/EmitterInterface.php
• https://github.com/iziphp/http-response-emitter/blob/main/src/EmitterInterface.php

Feature Request

Summary

To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.

In order to make this repository compatible, one has to follow these steps:

• Modify composer.json to provide support for PHP 8.0 by adding the constraint ~8.0.0
• Modify composer.json to drop support for PHP less than 7.3
• Modify composer.json to implement phpunit 9.3 which supports PHP 7.3+
• Modify .travis.yml to ignore platform requirements when installing composer dependencies (simply add --ignore-platform-reqs to COMPOSER_ARGS env variable)
• Modify .travis.yml to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!)
• Modify source code in case there are incompatibilities with PHP 8.0

Feature Request

Summary

SapiStreamEmitter::emit considers the header Content-Range and emits only the relevant range when only a single range is requested and the range unit is bytes. This seems very nice and convenient at first glance.

If the application wants to support multi-range requests or range units other than bytes, however, populating the response with the correct content range(s) must be done by the application, and SapiStreamEmitter will emit the entire provided response body.

This seems very asymmetrical to me. Who should actually be in charge of ensuring that the response body is correct? The one who populates the response body or the one who emits it?

My application would have to populate the final response body in the case of multi-range or non-byte unit, but populate the entire file into the response body in the case of single byte range, and then let SapiStreamEmitter handle the range-stuff. I would like the option to let SapiStreamEmitter just output the whole response body that I have provided, regardless of the Content-Range range header.

I actually don't think the Content-Range functionality has anything to do in the emitter, so I would prefer to just remove it. But such a change in functionality might warrant a new major version. The behavior could also be set in a constructor argument. Or there could be a separate class.

If the Content-Range functionality has anything to do in the emitter, why isn't it also a part of the SapiEmitter. In my opinion, exchanging the one for the other should not lead to different output.