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:
|
// 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.
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_ENABLEDexception 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
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
HttpConnectionPoolwhen 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
httpendpoint so we never even attempt HTTP/2.