The root_path is missing from the redirects from an url with trailing slash to the same url without it #2514
Replies: 2 comments 1 reply
-
|
Hello @Mattiam2 I have faced same issue today... Did you know how to pass it? |
Beta Was this translation helpful? Give feedback.
-
|
In the meanwhile because I use a reverse proxy (nginx), I've managed to "fix" the issue by specifying the root_path when using proxy_pass with the socket. Before: After: Or by just removing the arguments all together (in this way the full path will be used): This solution works enough for me but shouldn't be correct, because for the way root_path is defined within fastapi/starlette, fastapi socket shouldn't expect to have the root_path included in the url path. |
Beta Was this translation helpful? Give feedback.
-
|
Just chiming in to say this issue is still present. @Kludex - Should this be raised as an issue to be fixed? if the behaviour is intended, can you recommend a way of making redirects work when using |
Beta Was this translation helpful? Give feedback.
-
Issue opened also in the FastAPI discussions here.
Example Code
The program runs in gunicorn (using the uvicorn worker class) behind a nginx proxy which strips away the root_path (as described in Behind a proxy).
Before fastapi 0.109 (and before starlette 0.35.0) an URL with a trailing slash (ex. https://127.0.0.1/wms/hello/) would be redirected to the corresponding URL without the trailing slash (ex. https://127.0.0.1/wms/hello) as expected.
From fastapi 0.109 (and from starlette 0.35.0) the redirect no more includes the root_path, so from https://127.0.0.1/wms/hello/ the application redirects to https://127.0.0.1/hello which results in a 404 Not Found error.
Here the headers of the redirect request:
I think the issue came from this change which strips away the root_path from the path in the URL constructor which seems to me off, even considering the ASGI specs.
Beta Was this translation helpful? Give feedback.
All reactions