SignalR TS HttpConnection._resolveUrl fails if URL starts with "ws+unix:" (area-signalr)

[sschultze]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

If I, in a Node.js SignalR client, try to establish a connection to a ws+unix: URL (named pipes or Unix domain sockets), a "Cannot resolve" error is thrown in HttpConnection._resolveUrl.

If I change the _resolveUrl method so that it accepts any URL, everything works perfectly fine.

Expected Behavior

The HttpConnection._resolveUrl should accept URLs that start with ws+unix: (no check for forward slashes!) and leave them unchanged.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

8.0.100-rc.1.23463.5

Anything else?

ASP.NET Core 8.0.0-rc.1.23421.29

[BrennanConroy]

Where is ws+unix defined? Seems like it might be a custom feature of the ws node library? It certainly doesn't look like it would work in a browser: https://websockets.spec.whatwg.org/#ref-for-dom-websocket-websocket%E2%91%A0

url is a string giving the URL over which the connection is established. Only "ws", "wss", "http", and "https" schemes are allowed; others will cause a "SyntaxError" DOMException.

[sschultze]

I have done some research and ws+unix: indeed seems to be a custom feature of ws. Actually, there is even a suggestion to rename to protocol to ws+ipc:

websockets/ws#2079 (comment)

Is there really any value to even check URLs in _resolveUrl in non-browser environments?

[BrennanConroy]

Is there really any value to even check URLs in _resolveUrl in non-browser environments?

The main thing is that we'll throw an error instead of calling fetch and letting that API throw the error. It probably wouldn't be an issue to pass through any url in Node since that would allow IPC (or some other protocol) if the underlying http libraries supported it.

However, it's worth noting in this case, you would need to skip negotiation. Otherwise fetch will be called with ws+unix://... and fail.

You could also workaround this by wrapping ws in order to intercept the url we pass through so you can rewrite it to ws+unix: and then setting the wrapper class on the IHttpConnectionOptions.

new HubConnectionBuilder().withUrl("http://...", { WebSocket: wrappedWs });

[sschultze]

The main thing is that we'll throw an error instead of calling fetch and letting that API throw the error. It probably wouldn't be an issue to pass through any url in Node since that would allow IPC (or some other protocol) if the underlying http libraries supported it.

This would make it easy for me of course. However, the workaround you suggest (wrapping ws) should also be a good solution.

However, it's worth noting in this case, you would need to skip negotiation. Otherwise fetch will be called with ws+unix://... and fail.

Thank you for pointing me on this! I am actually already skipping negotiation. For those who are trying the same thing, it should be noted that in this case, you have to make sure that proper authorization is done on the named pipes / Unix domain sockets level (i.e. only the current user should be able to connect).

You could also workaround this by wrapping ws in order to intercept the url we pass through so you can rewrite it to ws+unix: and then setting the wrapper class on the IHttpConnectionOptions.

new HubConnectionBuilder().withUrl("http://...", { WebSocket: wrappedWs });

Thank you, as I said above, this workaround should be a good solution! I will do it this way.

[sschultze]

This is my (working!) implementation of the workaround. Unfortunately, the WebSocket property is not included in the public IHttpConnectionOptions interface, so I had to set it via (connectionOptions as any).WebSocket.

const connectionUrl = '...';

function wrappedWebSocket(_url: string, protocols?: string | string[], options?: any): WebSocket {
    return new WebSocket(connectionUrl, protocols, options);
}

wrappedWebSocket.CLOSED = WebSocket.CLOSED;
wrappedWebSocket.CLOSING = WebSocket.CLOSING;
wrappedWebSocket.CONNECTING = WebSocket.CONNECTING;
wrappedWebSocket.OPEN = WebSocket.OPEN;

const connectionOptions: IHttpConnectionOptions = {
    skipNegotiation: true,
    transport: HttpTransportType.WebSockets
};

(connectionOptions as any).WebSocket = wrappedWebSocket;

const hubConnection = new HubConnectionBuilder()
    .withUrl('http://localhost/this-url-is-not-used', connectionOptions)
    .build();

[BrennanConroy]

Closing as I don't think there is anything we want to do here at this time. If other similar requests come in or more scenarios appear we can reconsider. Fortunately, there is a workaround mentioned above.