You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 29, 2020. It is now read-only.
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.
#46 adds a 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?
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.
The text was updated successfully, but these errors were encountered: