Open aronatkins opened 1 month ago
Rolling back to older versions of (all the things) avoids the problems described here. This isn't a reasonable workaround, for sure, but does capture that there has been change to the treatment of application paths.
Using the following package installation (modifying the included Dockerfile) results in a Gradio application that does not show errors:
RUN PIP_ROOT_USER_ACTION=ignore pip3 install gradio==3.3.1 fastapi==0.85.2 httpx==0.24.1 uvicorn
Describe the bug
This problem likely overlaps with https://github.com/gradio-app/gradio/issues/8073 and https://github.com/gradio-app/gradio/issues/9101. The approach (using middleware) is different, which is why I'm filing it separately.
The application is hosted at
http://localhost:4080/gradio
, but sees requests forhttp://localhost:4080/assets/index-BOW2xVAS.css
andhttp://localhost:4080/theme.css
.Have you searched existing issues? 🔎
Reproduction
This Python script has several attempts to mount a Gradio application beneath a known root path. The two middleware approaches model our situation, as we determine the
root_path
based on incoming request information (an HTTP header). The middleware here is simplified and uses a staticroot_path
, but the idea is the same.The
RootPathMiddleware
andAllPathMiddleware
classes are similar; they are experiments that adjust onlyroot_path
or all ofroot_path
,path
, andraw_path
.This is the nginx configuration used to test against this application. It includes an
App-Base-URL
header, but it is not used by the Python code.The
docker-compose.yml
:The
Dockerfile
containing gradio and uvicorn:Screenshot
These screenshots were taken when using the
RootPathMiddleware
middleware, but other runtime options produced similar results.The unstyled application:
The 404 errors:
Logs
No response
System Info