Handle web socket downgrade when HTTP/2 not enabled

[greenEkatherine]

During manual testing of #73762 @BrennanConroy and me detected that in the case when HTTP/2 connection is not supported downgrade for web sockets is not working as expected.

In that case ClientWebSocket didn't get exception data indicating that downgrade is possible, so I added this data and tests for it.

However, it doesn't handle plain text scenario because HttpClient in that case silently create Http2Connection with no chance to detect the real version before we try to establish extended connect. If downgrade allowed by policy HttpClient force 1.1 without giving 2.0 a try -- maybe ClientWebSocket should do the same.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

During manual testing of #73762 @BrennanConroy and me detected that in the case when HTTP/2 connection is not supported downgrade for web sockets is not working as expected.

In that case ClientWebSocket didn't get exception data indicating that downgrade is possible, so I added this data and tests for it.

However, it doesn't handle plain text scenario because HttpClient in that case silently create Http2Connection with no chance to detect the real version before we try to establish extended connect. If downgrade allowed by policy HttpClient force 1.1 without giving 2.0 a try -- maybe ClientWebSocket should do the same.

Author:	greenEkatherine
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	-

[CarnaViire]

LGTM, thanks!

[Tratcher]

If downgrade allowed by policy HttpClient force 1.1 without giving 2.0 a try -- maybe ClientWebSocket should do the same.

Yes, ClientWebSocket should follow the same rules as HttpClient here.

[MihaZupan]

I agree we should match SocketsHttpHandler

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs

Lines 1037 to 1039 in 3db2ebf

	if (_http2Enabled &&
	(request.Version.Major >= 2 || (request.VersionPolicy == HttpVersionPolicy.RequestVersionOrHigher && IsSecure)) &&
	(request.VersionPolicy != HttpVersionPolicy.RequestVersionOrLower || IsSecure)) // prefer HTTP/1.1 if connection is not secured and downgrade is possible

If the scheme is not secure and the policy allows 1.1, we should not attempt 2.0.

[greenEkatherine]

I added condition to force to 1.1 non-secure web socket requests in ClientWebSocket @MihaZupan @Tratcher

[MihaZupan]

Does HTTP/2 over cleartext work with WebSockets right now?

SocketsHttpHandler requires that you use set both Version=2.0 and Policy=Exact for that.
From what I can see, we set only the version in WebSockets:

runtime/src/libraries/System.Net.WebSockets.Client/src/System/Net/WebSockets/WebSocketHandle.Managed.cs

Line 73 in feb0e27

request = new HttpRequestMessage(HttpMethod.Connect, uri) { Version = HttpVersion.Version20 };

[greenEkatherine]

Does HTTP/2 over cleartext work with WebSockets right now?

SocketsHttpHandler requires that you use set both Version=2.0 and Policy=Exact for that. From what I can see, we set only the version in WebSockets:

runtime/src/libraries/System.Net.WebSockets.Client/src/System/Net/WebSockets/WebSocketHandle.Managed.cs

Line 73 in feb0e27

request = new HttpRequestMessage(HttpMethod.Connect, uri) { Version = HttpVersion.Version20 };

VersionPolicy is set up later in the AddWebSocketHeaders

runtime/src/libraries/System.Net.WebSockets.Client/src/System/Net/WebSockets/WebSocketHandle.Managed.cs

Line 370 in feb0e27

request.VersionPolicy = HttpVersionPolicy.RequestVersionExact;

[greenEkatherine]

/azp run runtime-libraries-coreclr outerloop

[greenEkatherine]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[greenEkatherine]

Failures in the outerloop builds are unrelated