[BUG] OpenAPI routes do not acknowledge root_path
See original GitHub issueAlso raised on https://github.com/tiangolo/fastapi/pull/26#issuecomment-562755647. See also #544.
Describe the bug
Write here a clear and concise description of what the bug is.
To Reproduce
Replace each part with your own scenario:
- Create a file with:
from fastapi import FastAPI
app = FastAPI()
@app.get("/app")
def read_root():
return {"Hello": "World"}
- Launch it using
uvicorn --root-path="bar" test_app:app
- Open the browser and go to
http://127.0.0.1:8000/docs
. - From the documentation, call the
GET /app
route. - The doc page calls
/app
and succeeds.
Expected behavior
The above test should fail after having called /bar/app
, since root_path
is supposed to prefix all generated URLs in case the application is served behind a reverse-proxy, among ther things. FastAPI only acknowledges openapi_prefix
for the API doc.
Environment
- OS: Windows
- FastAPI Version: 0.45.0
- Python version: 3.8.0
Additional context
A similar issue applies to sub-applications:
from fastapi import FastAPI
app = FastAPI()
@app.get("/app")
def read_main():
return {"message": "Hello World from main app"}
#subapi = FastAPI(openapi_prefix="/subapi")
subapi = FastAPI()
@subapi.get("/sub")
def read_sub(request: Request):
return {
"root_path": request.scope['root_path'],
"raw_path": request.scope['raw_path'],
"path": request.scope['path'],
"app_url_for": app.url_path_for("read_sub"),
"subapp_url_for": subapi.url_path_for("read_sub"),
}
app.mount("/subapi", subapi)
{
"root_path":"bar/subapi",
"raw_path":"/subapi/sub",
"path":"/sub",
"app_url_for":"/subapi/sub",
"subapp_url_for":"/sub"
}
(url_for
not being prefixed with root_path
is fixed upstream by encode/starlette#699)
Unless openapi_prefix="/subapi"
is passed when creating the subapplication, both http://127.0.0.1:8000/docs
and http://127.0.0.1:8000/subapi/docs
will point towards http://127.0.0.1:8000/openapi.json
, which goes against the point of having isolated subapplications.
openapi_prefix
should probably just be deprecated and assumed to match root_path
if absent.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:14
- Comments:17 (8 by maintainers)
Top GitHub Comments
I feel that this is closely related to a question I was about to write, so I will post it here instead to avoid duplication.
– Hi, I’m deploying a minimal application written with FastAPI and Mangum as an adapter using AWS SAM. It works like a charm, and I’m in the process off writing an article about it to append in the fastapi documentation. Yet one thing that boggles my mind is the path of the /openapi.json and I can’t wrap my head around how to work it in different situations.
So let’s assume I have a little application like this:
I deploy it to API Gateway/Lambda to a stage called
prod
so the resulting url ishttps://xxxxxxxxxx.execute-api.eu-west-1.amazonaws.com/prod
. The API Gateway is set up with{proxy+}
integration. Now how is it, that the/ping
endpoint “knows” that the base-url is […].amazonaws.com/prod, yetopenapi.json
assumes to be at […].amazonaws.com/openapi.json?I know I can change the prefix with
openapi_prefix="/prod"
but that makes it inconvenient if I wanted to use another stage thanprod
. After all I don’t have to do it for my other endpoints either. So is there a reason it doesn’t work the same way as with my other endpoints? Is it a bug, or am I just missing something very obvious?Recently ran into this issue and the best solution I could think of was monkey patching
openapi.json
:Not elegant, but this did exactly what I was looking for: serving my API at
/api/v1/
with swaggerui working as expected.Edit: I had to declare separate openapi functions because I wanted to protected them using basic auth, which is not used for anything else in the app (dependencies not shown above for clarity).
FYI, I’m running behind NGINX in docker-compose which looks like this:
Edit 2: the above can be achieved in a simpler way with a downside (or upside) of the “servers” drop-down appearing and the
/api/v1
prefix disappearing: