handle websocket requests to non-websocket targets

[minrk]

relay response status and body back to requester

Honestly, the most relevant part of this is just closing the socket on the response event, because browser websockets don't really handle HTTP errors at all, they are all just treated as "not a websocket".

But in this PR, the status and body are proxied back. It doesn't go through the full behavior of proxy.web (notably: headers are not preserved). I couldn't figure out the easiest way to properly preserve proxy passes from web-outgoing since we don't have a res object. If a res can be accessed and/or mocked so that the web-outgoing passes can be applied as-is, that should be fully proxied. In the absence of correctly proxied headers, I'd also be okay discarding the body and just proxying the status line with Connection: close.

closes #26

[minrk]

Looks like this was removed in the typescript refactor.

The code exactly as-is from node-http-proxy doesn't work anymore due to mishandling of transfer-encoding: chunked in proxyRes.pipe(socket), I believe.

[Copilot]

Pull Request Overview

This PR adds functionality to handle WebSocket upgrade requests that are made to non-WebSocket backends. When a WebSocket connection attempt is made to an HTTP-only endpoint, the proxy now relays the HTTP response status and body back to the client before closing the connection.

• Added response event handler in the WebSocket proxy to detect non-WebSocket responses
• Implemented HTTP response forwarding with status code and body preservation
• Added comprehensive test coverage for WebSocket-to-HTTP scenarios

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
lib/test/websocket/websocket-proxy-http.test.ts	New test file covering WebSocket client connections to non-WebSocket backends
lib/http-proxy/passes/ws-incoming.ts	Added response event handler to relay HTTP responses when backend doesn't support WebSockets

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[williamstein]

The code exactly as-is from node-http-proxy doesn't work anymore due to mishandling of transfer-encoding: chunked in proxyRes.pipe(socket), I believe.

I didn't quite follow how this relates to the rest of your PR.

[minrk]

I didn't quite follow how this relates to the rest of your PR.

Just that one solution is to put back exactly what was there instead of what I did here, but it leads to:

Serialized Error: { bytesParsed: 167, code: 'HPE_INVALID_CHUNK_SIZE', reason: 'Invalid character in chunk size', rawPacket: '<Buffer(183) ...>' }

[minrk]

I figured out a way to fully proxy the response (unlike node-http-proxy, which didn't put response headers through the web-outgoing passes). I don't fully understand the transfer-encoding problem. Removing the transfer-encoding header from the response avoids an error. I suspect it has to do with using proxyRes.pipe(socket) instead of proxyRes.pipe(res) which should handle transfer encoding? I don't know. Or maybe the header is wrong.

[minrk]

ok, I understand transfer-encoding better now - since it's hop-by-hop, the outgoing body shouldn't have any relation to the transfer-encoding of the proxied request, so removing this header is the right thing to do (always, not just for this websocket case).

I also realize this issue: http-party/node-http-proxy#1488 is still unaddressed and that there are other headers that should likely be unconditionally rewritten (or just removed) in web-outgoing, but that's another PR:

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• TE
• Trailers
• Transfer-Encoding
• Upgrade

[minrk]

opened #28 for the hop-by-hop headers in general, but fixed transfer-encoding here because it's actually needed when writing directly to a socket instead of to a Response, which implements the transfer encoding itself.

[williamstein]

OK, this looks good to me.