WebSockets downgrade to 1.1 on network failure during TLS handshake

[MihaZupan]

Managed WebSocket will attempt to downgrade to HTTP/1.1 if we failed to establish HTTP/2 and the version policy permits.

The logic currently sets HTTP2_ENABLED exception data if we fail to establish TLS:

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

Lines 94 to 96 in cb1343d

	// Extended connect request is negotiating strictly for ALPN = "h2" because HttpClient is unaware of a possible downgrade.
	// At this point, SSL connection for HTTP / 2 failed, and the exception should indicate the reason for the external client / user.
	ex.Data["HTTP2_ENABLED"] = false;

This is weird. That failure could be caused by the network and has nothing to do with whether the server supports HTTP/2.
As a result, we will end up retrying on HTTP/1.1 even though we normally wouldn't (and SocketsHttpHandler wouldn't either).

We should be able to just delete this check entirely - actual ALPN issues will be caught later in HttpConnectionPool when we attempt to retry an HTTP/2-only request on the downgraded 1.1 connection.

The current downgrade tests don't exercise this as they are connecting to an http endpoint so we never even attempt HTTP/2.

[ghost]

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

Issue Details

---

Managed WebSocket will attempt to downgrade to HTTP/1.1 if we failed to establish HTTP/2 and the version policy permits.

The logic currently sets HTTP2_ENABLED exception data if we fail to establish TLS:

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

Lines 94 to 96 in cb1343d

	// Extended connect request is negotiating strictly for ALPN = "h2" because HttpClient is unaware of a possible downgrade.
	// At this point, SSL connection for HTTP / 2 failed, and the exception should indicate the reason for the external client / user.
	ex.Data["HTTP2_ENABLED"] = false;

This is wrong. That failure could be caused by the network and has nothing to do with whether the server supports HTTP/2.
We should be able to just delete this check entirely - actual ALPN issues will be caught later in HttpConnectionPool when we attempt to retry an HTTP/2-only request on the downgraded 1.1 connection.

The current downgrade test does not exercise this. It connects to an http endpoint so we never even attempt HTTP/2.
dotnet/aspnetcore#43851 is adding many E2E tests that better cover downgrades.

Author:	MihaZupan
Assignees:	-
Labels:	bug, area-System.Net
Milestone:	-

[karelz]

Triage: This may be by design (due to implementation), and if it is not, then the impact on customers is super-small - we will establish 1.1 connection in more cases than we should (when H/2 connection failed due to network error).
Either way, not critical for 7.0. We should decide in 8.0 if it is by design, or if we need a change.

[dotnet-policy-service]

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