New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Last middleware can invoke next #300
Conversation
0b33c94
to
67a32f2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! I think it makes perfect sense to address this 👍
@@ -48,6 +48,10 @@ public function call(ServerRequestInterface $request, $position) | |||
return $that->call($request, $position + 1); | |||
}; | |||
|
|||
if (!isset($this->middleware[$position])) { | |||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about returning null
here as this would break the middleware specification (see README).
It's my understanding that this would be an error, so it should probably throw
instead (php.net/manual/en/class.outofrangeexception.php)?
As an alternative, we could also use this to create a "default response", i.e. some kind of response factory and just return a "default response" here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is, that it should behave like the middleware just didn't return anything because $next()
invoked from the last middleware is just no-op because there is no next.
$middleware = new MiddlewareRunner(array(
function (RequestInterface $request, $next) {
// no-op
}
));
Since the MiddlewareRunner is internal and null
will produce an error, i think that this is an acceptable behaviour.
If we throw, we probably should explicitly document, that calling $next()
from the last middleware is forbidden or just not pass $next()
to the last middleware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[…] there is no next. […] just not pass $next() to the last middleware.
Now that you've said this, I think this actually makes most sense. The last request handler in the chain should not be allowed to call the "next".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't pass $next
, then the last middleware callable must have a different signature. I'd rather then pass a $next()
which throws.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're raising a very good point here. I've just filed #308 to implement this as suggested. Let me know what you think 👍
Allows the last middleware in MiddlewareRunner to invoke
$next()
.Example
See eg. https://travis-ci.org/jsor-labs/http/jobs/329394945 for a failing test.