Duplicated root-path on 307 redirection

[tsunday]

Starlette redirects on missing or redundant trailing slash. In pair with additional --root-path parameter on uvicorn it redirects to a wrong URI. Looks like starlette appends the same URI with filled or removed slash, but it's not considering root-path configuration, so that the path contains duplicated root.

To reproduce

1. Configure endpoint without trailing slash - e.g. /products
2. Execute starlette application with uvicorn and pass --root-path parameter - e.g. /api/v1/
3. Call your endpoint with a redundant trailing slash - /api/v1/products/
4. Check 307 redirection path on your logs

Expected behavior

Starlette redirects to /api/v1/products

Actual behavior

Starlette redirects to /api/v1/api/v1/products

Debugging material

Environment

• OS: Linux/MacOS
• Python version: 3.9.0
• Starlette version: 0.13.6

[HassanAbouelela]

I tested this with Windows, Python 3.9, on the master branch of starlette, but could not reproduce. Making a request to /api/v1/products/ would immediately 404 with no redirections. I could however get what you described by making the request directly to /products/. That is not a bug.

This seems like a misunderstanding of what root path does. Admittedly, the documentation on this option is a bit limited. fastapi has a better description of what the option does here.

To demonstrate this issue, there will be three parts to my app:

• The frontend hosted at example.com/api/v1
• The backend hosted at api.com
• A proxy that converts traffic from example.com/api/v1 to my backend, stripping /api/v1 from the path.

Navigating to example.com/api/v1/products/ returned a redirection to example.com/api/v1//products. The client then makes a request to example.com/api/v1//products, where the proxy converts the request to api.com/products. This would return the correct response.

Without the proxy, the response would indeed be a 404. If you look at the logs, they'll say the 404 was at /api/v1/api/v1//products, but that's just a display feature to help in logging. Without the proxy, which seems to be your case here, the actual request was made to api.com/api/v1//products, which is indeed a 404, as the route is /products not /api/v1/products.