-
Notifications
You must be signed in to change notification settings - Fork 327
Default Handler Implementation #64
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
Conversation
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.
This nicely addresses my suggestion on always-applied middleware at #61 (comment)! However, there are some points that we can get it better, so I left a suggestion.
Some thoughts:
- You can make
params
optional if you like. It's totally okay if you don't -- I'll do it then. - This is an open question: if the path matched but the endpoint for our method is not there, what middleware should be run? In this case, we also have resource-specific middleware chain and actual wildcard matches.
@tirr-c I've gone ahead and made |
I've gone ahead and split apart the |
src/head.rs
Outdated
Ok(t) => future::ok(Path(t)), | ||
Err(_) => future::err(http::status::StatusCode::BAD_REQUEST.into_response()), | ||
}, | ||
None => future::err(http::status::StatusCode::BAD_REQUEST.into_response()), |
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 trying to extract match information from default handlers is a bug in application code. One should know that there's no wildcard match in default handler. Maybe INTERNAL_SERVER_ERROR
is better, or... should panic 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.
Haha yeah...I am hesitant to panic but I did make it INTERNAL_SERVER_ERROR
. I guess I could make it panic? I dunno what to do here 😢
09528e0
to
0ff73cf
Compare
0ff73cf
to
f6cf725
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.
You're very close!
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.
LGTM, let's wait for travis!
So this should tackle #10 .
Little bit of info on what is happening here,
The call to router will no longer return
Some(RouteResult)
and instead always returns aRouteResult
. The router will fallback to thedefault_handler
that is set. This allows us to use all middleware that are set in themiddleware_base
of the root router. In the example, you can try it and see that logging is now working for the fallback route.I'm not going to lie, this particular PR was probably a bit above my Rust level and feels a bit hacky to me. Let me know what you guys think!
Also, special thank you to @tirr-c for his countless hours answering my non-stop questions ❤️
TODO:
I'd like to write some tests but I will wait until the final implementation to do so. Let's hold off on merging this at least until some tests are written 😄