Open s100 opened 3 months ago
Thanks for the feedback @s100!
In the HPM v3, the path
argument in pathFilter
is provided by the webserver you are using (req.url
).
Same goes for the path stripping behaviour and the full path with WebSockets.
Across different servers paths are getting quite messy (to get the full path as seen in the logger) 😅 https://github.com/chimurai/http-proxy-middleware/blob/2e5ccac41edf3ede465f705e5b76481b74d03b8f/src/plugins/default/logger-plugin.ts#L25-L30
I'll have to investigate this and decide whether to keep the new behaviour with extra documentation or patch the path
.
Thanks for the update. By the way I noticed a small but significant typo in my original issue, which I have now corrected.
I'm facing the same issue. In my opinion, both the proxied HTTP and WebSocket URLs should follow the same format. Otherwise, the upstream URLs will differ for both.
As a workaround, I'm using custom pathRewrite to remove the base path from the URL, if it exists, to make the URLs consistent for both HTTP and WebSocket requests.
Checks
http-proxy-middleware
.Describe the bug (be clear and concise)
When
http-proxy-middleware@3
receives a HTTP request, it passes the HTTP request URL to your configuredpathFilter
and uses this to determine whether or not to proxy this request through. With most requests, the base URI on which the middleware is mounted is removed from the URL. But for a WebSocket upgrade the base URI is left on.Step-by-step reproduction instructions
This isn't a fully functional reproduce but it should give an idea. I have HPM configured like so:
Then the application listens on http://localhost:5056.
Expected behavior (be clear and concise)
When I make a HTTP request to http://localhost:5056/a/b/c/api/whatever, the console outputs:
, my filter returns
true
and HPM proxies the request through, correctly. Note how "/a/b/c" has been removed frompathname
.But when my application tries to open a web socket on http://localhost:5056/a/b/c/raw-ws, the console outputs:
, the filter returns
false
, and my filter does not proxy the request through. Currently I am working around this by altering my filter to say:How is http-proxy-middleware used in your project?
What http-proxy-middleware configuration are you using?
What OS/version and node/version are you seeing the problem?
Additional context (optional)
Big fan of the V3 upgrade because it's taken a lot of manual base path management off my hands! Just this last little bit :)