V3: base path not stripped from WebSocket upgrade requests

[s100]

Checks

• I understand project setup issues should be asked on StackOverflow or in GitHub Discussions.
• I updated to latest 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 configured pathFilter 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:

app.use('/a/b/c', createProxyMiddleware({
  target: 'http://localhost:4415',
  ws: true,
  pathFilter: pathname => {
    console.log(pathname)
    return pathname.startsWith('/api') ||
      pathname.startsWith('/raw-ws')
})

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:

/api/whatever

, my filter returns true and HPM proxies the request through, correctly. Note how "/a/b/c" has been removed from pathname.

But when my application tries to open a web socket on http://localhost:5056/a/b/c/raw-ws, the console outputs:

/a/b/c/raw-ws

, 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:

pathname.startsWith('/api') ||
  pathname.startsWith('/a/b/c/raw-ws')

How is http-proxy-middleware used in your project?

*****@9.0.688
`-- http-proxy-middleware@3.0.0

What http-proxy-middleware configuration are you using?

{
  target: 'http://localhost:4415',
  ws: true,
  pathFilter: pathname => {
    console.log(pathname)
    return pathname.startsWith('/api') ||
      pathname.startsWith('/raw-ws')
}

What OS/version and node/version are you seeing the problem?

Windows, Node.js 18.17.1

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 :)

[chimurai]

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) 😅

http-proxy-middleware/src/plugins/default/logger-plugin.ts

Lines 25 to 30 in 2e5ccac

	proxyServer.on('proxyRes', (proxyRes: any, req: any, res) => {
	// BrowserSync uses req.originalUrl
	// Next.js doesn't have req.baseUrl
	const originalUrl = req.originalUrl ?? `${req.baseUrl || ''}${req.url}`;
	const exchange = `[HPM] ${req.method} ${originalUrl} -> ${proxyRes.req.protocol}//${proxyRes.req.host}${proxyRes.req.path} [${proxyRes.statusCode}]`;
	logger.info(exchange);

I'll have to investigate this and decide whether to keep the new behaviour with extra documentation or patch the path.

[s100]

Thanks for the update. By the way I noticed a small but significant typo in my original issue, which I have now corrected.

[Chiragasourabh]

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.

[sebastianfrey]

In my case this issue caused all websocket upgrade requests to fail. After rewriting the path manually for websocket upgrade requests, everything worked as expected:

  pathRewrite: (path, req) => {
    if (req.headers['upgrade'] === 'websocket') {
      return path.replace(new RegExp(`^${appContext}`), '');
    }
    return path;
  },