Closed bogutskyy closed 7 years ago
Also I guess the documentation for FinalHandler contains some mistakes
Internally, FinalHandler does the following on invocation:
If $error is non-null, it creates an error response from the response provided at invocation, ensuring a 400 or 500 series response is returned.
If the response at invocation matches the response provided at instantiation, it returns it without further changes. This is an indication that some middleware at some point in the execution chain called $next() with a new response instance.
If the response at invocation does not match the response provided at instantiation, or if no response was provided at instantiation, it creates a 404 response, as the assumption is that no middleware was capable of handling the request.
For example, if the response at invocation matches the response provided at instantiation it doesn't mean that some middleware in the execution chain called $next() with a new response instance. It mean that the response provided at instantiation is the same.
setOriginalResponse()
method to the FinalHandler
, allowing you to inject it after instantiation. I think that addresses one aspect of the issue you're reporting.Could you provide some sample unit tests showing the behavior you expect, by any chance?
The FinalHandler
was deprecated in 1.3.0, and will be removed in the upcoming 2.0.0, resolving this issue.
Maybe it's a good thought to mark the original response as mandatory in https://github.com/zendframework/zend-stratigility/blob/develop/src/FinalHandler.php#L45? Otherwise, if an original response is null then in an invocation, even if some middleware had handled the request correctly, without errors, always will be created 404 error.