Basepath not retained in proxied requests

[norelina]

Bug description

Basepath not retained in proxied requests when using route created in CHP

How to reproduce

1. Run a simple React app locally
2. Run CHP locally using configurable-http-proxy --port 8500 --log-level debug
3. Create a route for the React app
4. Try to access the React app through the proxy

Expected behaviour

Static files cannot be loaded and return 404s. Trying to load it using: http://localhost:8500/static/js/bundle.js

Actual behaviour

The basepath /react of the route is not maintained.

Static file should be loaded by: http://localhost:8500/react/static/js/bundle.js

Notes:

• When we add the --no-include-prefix the file is indeed available in route http://localhost:8500/react/static/js/bundle.js (we would expect the opposite), but the basepath is still not maintained.
• Absolute paths are used for the static files (this is not something we have control over in our case)

Your personal set up

This has been reproduced in Windows 11, Mac, and also in an Azure Kubernetes cluster.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[minrk]

Sorry, I just realized I never posted the answer I meant to give long ago.

CHP does not add prefixes to requests that come in or HTML that passes through, so to work with proxied prefixes, HTML/js served by proxied applications must use either absolute URLs and be told their base URL (/react/some/url) or use relative URLs (./some/url). If using relative URLs, it is important to access the root of a proxied URL with the trailing slash, as URLs relative to /react/ are not the same as relative to /react: /react will resolve foo.js as /foo.js, whereas /react/ will resolve it to /react/foo.js. CHP isn't involved in any of this, though; that's purely the browser. The only choice CHP makes here is to route both /react and /react/ the same, when perhaps it should really 404 on /react.

This missing trailing slash on /react in your screenshot may turn out to be the whole issue you are facing, I'm not sure.

The --no-include-prefix strips the proxy prefix from proxied requests, so a browser request for /react/foo.js will arrive at the server as /foo.js instead of the unmodified /react/foo.js.

Hope that helps or you figured it out yourself long ago. Sorry for leaving you hanging.