search

jupyterhub / configurable-http-proxy

node-http-proxy plus a REST API
BSD 3-Clause "New" or "Revised" License
239 stars 127 forks source link

Basepath not retained in proxied requests #518

Open norelina opened 9 months ago

norelina commented 9 months ago

Bug description

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

image

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

image

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:

Your personal set up

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

welcome[bot] commented 9 months ago

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
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. welcome 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! :wave:
Welcome to the Jupyter community! :tada:

minrk commented 4 weeks ago

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.