-
Notifications
You must be signed in to change notification settings - Fork 20
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
Paths are not matched in order #3
Comments
Yes, this was definitely a good catch and, yes, sadly it is an issue in Werkzeug. In researching the problem, I was further disappointed to see it's been a known issue for over a year: pallets/werkzeug#185 I'm not surprised they haven't fixed it, though; the sorting seems to have been part of routing system's design. A misguided one, I believe, but someone, somewhere is relying on this behavior, bafflingly enough. For those too lazy to click the links in my explanation above, TL;DR: Regardless of insertion order, Werkzeug sorts routes by the number of arguments and "weight". Weight is the heuristically computed complexity of checking if a route matches. This includes going as deep as a As to why sorting is misguided:
I mean, how many routes did the Pocoo dudes have? 200+? The sorting functionality should be a Anyhoo, I'm working around this right now. Seemingly every web framework complicates routing, but not Clastic, anymore: Clastic routes will stay in insertion order. |
Alright, fix is pushed, I'll update PyPI shortly. Also, re: the 404, I know it's a little bit confusing, but it's consistent with all the other segment converters. Also, it usually works out such that root urls like You can, of course, reuse the same endpoint function by setting a default on that argument. The original endpoint function: def api(api_path):
return 'api: %s' % api_path Reusable endpoint function, via default value for the def api(api_path=None):
if api_path is None:
return 'api: api_path is None'
return 'api: %s' % api_path Thanks again for the great catch/report! |
Visiting /api/ results in a 404, which is arguably wrong depending on we think a "" should work.
Visiting /api/a results in "api: a", which is right.
Visiting /api/a/b results in "three_segments: api, a, b", which is batshit crazy.
Visiting /api/a/b/c results in "api: a/b/c", which is right.
Mahmoud said:
The text was updated successfully, but these errors were encountered: