-
Notifications
You must be signed in to change notification settings - Fork 176
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
Middlewares aren't called if there's no matched route #44
Comments
I don't agree with you. The only problem here is documentation. Not code. Put in the documentation that middlewares that are if your premise is
you are wrong
Refs:
TL;DR: it's not a bug, it's a feature. |
Yes, I wrote in the first line of the initial comment that this has been discussed before. I've seen it. I took the time to write this issue and this PR especially to discuss this more, and possibly decide to change the intended behavior. I understand this wouldn't be a light decision, so I would totally expect some sort of discussion. That's why I came with arguments and a use case. And to be honest I expect a bit more than "nope, it's expected, we always did this so we'll always do this." Thanks for reading! |
For me it's about cross cutting concerns. Current case:
You do not have to know what's inside router1 and router2 if testing your websocket stuff. You said "give me the routes middleware". You have one way to do one thing. Your case:
Here you said "give me the routes middleware and also every middleware you used on the router that will NOT match a route", weird 🤔 More importantly: Now there are two ways to do one thing (run a global middleware), and no way to do the other thing: NOT run used middleware on the router when nothing matched. In the current case: there are no wins, but there are no loss, in terms of functionality. You already have your solution: move In your case: we gained another way to define a global middleware, and we lost the granularity of a global middleware scoped to the router when something is matched. I consider this a loss. Now I'm asking you to define a middleware that is only going to be run when a route is matched in a concise way, can you do it ? There is also a workaround, duplicate the middleware across all In hope that I was clear, have a good day ! |
I found that this was also discussed in the old repository in ZijianHe/koa-router#182 ZijianHe/koa-router#257 ZijianHe/koa-router#239.
The problem can be seen with a code like this. The testcase could be made simpler but I left it like this so that it's closer to my real-world case, implementing CORS.
This is a curl command you can use to test this (this is a socalled "preflight CORS request"):
The answer should be something like:
But instead it is:
This shows that this is the middleware of
allowedMethods
that runs, instead of the "cors" middleware.Note this does work:
My main issue is that there's a surprise here: the router doesn't behave like koa and ignores all middleware if there's no matching route, and it's not documented anywhere. Koa instead will always run all middleware.
After various tries, I believe that this simple patch makes it work properly and doesn't have much impact:
Please tell me if you'd like that I do a PR with some test changes, I can do it.
The text was updated successfully, but these errors were encountered: