Pretty basic usage. This worked with netcoreapp2.0 and SDK 2.1.200 (verified this fails in the same way against the same endpoint as used then, before RemoteCertificateValidationCallback was added, so I don't think that is directly involved.)
.NET Core SDK Version 2.1.300, target framework netcoreapp2.1
using (var socket = new ClientWebSocket())
{
var options = socket.Options;
options.RemoteCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) => true;
await socket.ConnectAsync(uri, CancellationToken.None);
produces the following exception:
System.Net.WebSockets.WebSocketException (0x80004005): Unable to connect to the remote server ---> System.ArgumentException: The base stream is not writeable.
Parameter name: stream
at System.Net.WebSockets.WebSocket.CreateFromStream(Stream stream, Boolean isServer, String subProtocol, TimeSpan keepAliveInterval)
at System.Net.WebSockets.WebSocketHandle.ConnectAsyncCore(Uri uri, CancellationToken cancellationToken, ClientWebSocketOptions options)
at System.Net.WebSockets.WebSocketHandle.ConnectAsyncCore(Uri uri, CancellationToken cancellationToken, ClientWebSocketOptions options)
at System.Net.WebSockets.ClientWebSocket.ConnectAsyncCore(Uri uri, CancellationToken cancellationToken)
at Test.Program.Run(String uriArg) in C:\\Test\\Program.cs:line 34
Can you please share more information about this repro? What server is this connecting to? Perhaps also share WireShark traces? We need to reproduce this problem and need code that we can compile and debug. Thx.
Some additional information.
response.Content.ReadAsStreamAsync().Result.CanWrite
false
response.Content.ReadAsStreamAsync().Result.CanRead
true
response.Content.ReadAsStreamAsync().Result.GetType()
{System.Net.Http.HttpConnection+EmptyReadStream}
Response from the server on upgrade via Wireshark (I think this is what you are looking for?)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: TmMCWd4jT43v0kanKx+jxQsRt0E=
Content-Length: 0
And, if it matters, the request itself:
GET / HTTP/1.1
X-Forwarded-For: 10.xx.xx.xx
X-Forwarded-Proto: https
X-Forwarded-Port: 6600
Host: xxxx.yyyy.net:6600
X-Amzn-Trace-Id: Root=x-xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: b/sW+V6ha0eKZcg+BZ7kqQ==
Test program:
```c#
using System;
using System.Diagnostics;
using System.Net.WebSockets;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace Test
{
class Program
{
static void Main(string[] args)
{
Run(args[0]).Wait();
}
private static async Task Run(string uriArg)
{
if(!Uri.TryCreate(uriArg, UriKind.Absolute, out var uri))
{
Console.Error.WriteLine($"Failed to parse URI {uriArg}");
Environment.Exit(-1);
}
using (var socket = new ClientWebSocket())
{
var options = socket.Options;
options.RemoteCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) => true;
await socket.ConnectAsync(uri, CancellationToken.None);
}
}
}
}
```
uriArg
Since you didn't specify the argument in the sample above, could you try this uri and let us know if you see the problem?
ws://corefx-net.cloudapp.net/WebSocket/EchoWebSocket.ashx
or
wss://corefx-net.cloudapp.net/WebSocket/EchoWebSocket.ashx
Test page for that endpoint is here:
http://corefx-net.cloudapp.net/websocket/ or
https://corefx-net.cloudapp.net/websocket/
Your test endpoint works fine. The response packet differs, as follows:
HTTP/1.1 101 Switching Protocols
Cache-Control: private
Upgrade: Websocket
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
Sec-WebSocket-Accept: vjLFmdTyU5OKSXB+xSK/Yf5/eRc=
Connection: Upgrade
X-Powered-By: ASP.NET
Date: Fri, 08 Jun 2018 17:54:35 GMT
Note no content length header. Not sure if the WebSocket protocol specifies the behavior here?
The RFC is silent on the presence or content of the Content-Length header, or content, near as I can tell.
https://tools.ietf.org/html/rfc6455#page-22
This looks like https://github.com/dotnet/corefx/pull/29948 (ported to 2.1.1 in https://github.com/dotnet/corefx/pull/29993).
@ChronosWS would you be able to try release/2.1 daily build to see if the problem is addressed for your repro?
Verified fixed on SDK 2.1.400-preview-008963 with runtime 2.1.1-servicing-26605-02.
Thanks!
Thanks for verifying :)
@ChronosWS thanks a lot for confirmation!
Most helpful comment
This looks like https://github.com/dotnet/corefx/pull/29948 (ported to 2.1.1 in https://github.com/dotnet/corefx/pull/29993).