WebSocketTransport does not support proxy at SignalR Client
RyanWang-Git opened this issue · 10 comments
I am using Microsoft.AspNetCore.SignalR.Client to connect to SignalR Hub via WebSocketsTransport from .NET Core 2.0 console app and the connection is made via proxy.
The connection got through the negotiation phase OPTIONS successfully, however I encountered the following exception.
System.Net.WebSockets.WebSocketException (0x80004005): Unable to connect to the remote server
The connection works fine via proxy if I choose ServerSentEventsTransport or LongPollingTransport. After looking into WebSocketsTransport implementation in Microsoft.AspNetCore.Sockets.Client.Http, I noticed that no proxy setting is actually passed in and assigned to ClientWebSocket to initiate the WebSocket handshaking.
Is this going to be fixed in the next release?
Are you using IIS? If so, what version of Windows you are running and did you enable webSockets in IIS?
WebSocket works perfectly in non-proxy environment. The WebSocketTransport I am referring to is at SignalR client and I am using it in Console app and no IIS is used. My OS version is Windows 10 Pro.
What proxy is your server behind and does it have websockets enabled?
I don't think it has anything to do with the proxy at the server side. My console SignalR client works fine via WebSocketsTransport without proxy.
There must be some kind of communication error here. If websockets works without the proxy but doesn't work with the proxy then it should be fairly safe to assume the issue has something to do with the proxy right?
Yes, it is something to do with proxy at the client side, not the server side.
I have updated the title to make it specific to SignalR client.
@BrennanConroy Sorry, I think I misunderstood your question. I use Squid proxy and the Websocket is enabled.
I also used fiddler to try to capture the traffic going out and found no websocket handshaking traffic (CONNECT http method) going out at all but I did see negotiation traffic (OPTIONS http method). So I suspected that the fiddler proxy is not even used by ClientWebSocket.
It looks like SQUID only supports the CONNECT tunneling through the proxy for websockets requests. Try using https with our client which should do the tunneling.
@BrennanConroy Same issue.
By looking into the implementation of WebSocketsTransport at https://github.com/aspnet/SignalR/blob/dev/src/Microsoft.AspNetCore.Sockets.Client.Http/WebSocketsTransport.cs where _webSocket.Options is set nowhere. So from SignalR client's perspective, the settings are not passed down to ClientWebSocket, such as Proxy, KeepAliveInterval, Credentials, Cookies and request header.
@RyanWang-Git Good point, we should plumb those options through. We'll look at getting that done for the next preview release.