zendframework / zend-stratigility

Middleware for PHP built on top of PSR-7 and PSR-15
BSD 3-Clause "New" or "Revised" License
235 stars 57 forks source link

Original response in FinalHandler #43

Closed bogutskyy closed 7 years ago

bogutskyy commented 8 years ago

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.

bogutskyy commented 8 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.

weierophinney commented 8 years ago

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?

weierophinney commented 7 years ago

The FinalHandler was deprecated in 1.3.0, and will be removed in the upcoming 2.0.0, resolving this issue.