-
-
Notifications
You must be signed in to change notification settings - Fork 955
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
router.get("/?") no longer works #1008
Comments
This seems to be linked with these changes in It also seems to be linked with path including regexp meta character. This would make sens since Commit introducing these changes: |
It's also failing with others such as /.* |
Also duplicated in #1010. |
The Of the cases mentioned, I'd suggest...
|
This tends to drop CORS headers in the 307 redirect, so in actuality route.get("") and route.get("/") are fundamentally different despite documentation suggesting to use the later for the root endpoint. Likewise route.get("/?") formerly would serve both routes instead of performing a redirect. At any rate, this difference in behavior- whether an implementation bug or not deserves more than a minor version upgrade, as it introduces a breaking change in the routing behavior. Additionally, it deserves better documentation |
Could we try to aim for a little more goodwill here, please? I understand why it's frustrating. Having said that, the PR was a bugfix release, it wasn't obvious that folks were relying on buggy behaviour, and nobody flagged it up as problematic. It had never occurred to me that eg. |
Sorry, I appreciate all the hard work you have put into this lib and I feel strongly because it generally works well enough to use. I disliked the response because it felt dismissive of how people are using starlette and that something that seemed like a minor change was actually breaking for a subset of users, especially with immediately closing the issue without discussion. I do think that there are improvements to be had and probably most of them are in docs (i.e. docs should use consistent trailing slashes and note how the trailing slash redirects work) If it were me personally, I would revert the change and reapply it with a larger version and additional documentation around known behavioral changes. I know you have a ton of issues to fix so this probably won't happen. Best |
Yeah, that's worth considering. Good point. |
People are really creative .. frequently more than you'd expect I actually got the suggestion for "/?" from the FastAPI author based on starette supporting regex. As mentioned before, the 307 behavior could use a little more documentation |
Just wanted to give a positive feedback, this one works perfectly for my use case, thanks a lot. |
I'm using |
@inikolaev I'm not sure what you mean. I don't believe either uvicorn or |
Ok, I probably have misinterpreted you comment:
But then, does |
Have a dig into exactly what's happening there. What URL are you accessing? What is the route mounted as? What status code is being returned? |
Ok, I didn't remove |
Ok, my bad, my reproducer also works by returning 307, but I checked for I debugged through the code and noticed that router explicitly send 307 without a slash. Is it possible to do internal redirect instead? I don't really care whether endpoint ends with slash or not - I would like to handle it regardless and avoid this extra round trip. Or does uvicorn handles this redirect and it doesn't actually getting sent over the wire? |
You can stack ie
Or
Otherwise starlette will 307 to the one you define |
That was a very good workaround |
I think this is related to https://github.com/encode/starlette/pull/932/files
Formerly you could use router.get("/?") to represent router.get("") & router.get("/"), but now it returns a 404 error as of the latest version
I'm seeing this in FastApi (mentioned here fastapi/fastapi#1648 )
The text was updated successfully, but these errors were encountered: