WebSocketTests.FalseUpgradeTest fails when DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1

[davidni]

Describe the bug

Unit test WebSocketTests.FalseUpgradeTest fails on both netcoreapp3.1 and netcoreapp5.0 when environment variable DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1.

This is likely by design at the moment (in which case having this issue around will help future people who may hit this). YARP currently always attempts to issue outgoing calls as HTTP/2. And when this env var is set, the outgoing HTTP stack will indeed honor that and issue an HTTP2 unencrypted request. However the simulated target server tries to handle it as HTTP/1.1 (which makes sense, since there's no ALPN step without TLS).

To Reproduce

• Set environment variable DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1
• Run Microsoft.ReverseProxy.FunctionalTests unit tests

Unit test WebSocketTests.FalseUpgradeTest fails:

 Microsoft.ReverseProxy.WebSocketTests.FalseUpgradeTest
   Source: WebSocketTests.cs line 127
   Duration: 505 ms

  Message: 
    Assert.Equal() Failure
    Expected: OK
    Actual:   InternalServerError
  Stack Trace: 
    WebSocketTests.FalseUpgradeTest() line 154
    --- End of stack trace from previous location ---

Digging deeper, when ReverseProxy issues the outgoing request to the simulated target destination, the destination server is encountering the following exception from Kestrel:

Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Unrecognized HTTP version: ''
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpParser`1.RejectUnknownVersion(Int32 offset, ReadOnlySpan`1 requestLine)

Possible solutions

1. Do not always attempt HTTP/2 on outbound requests; perhaps only attempt HTTP/2 if the outbound request is using https?
2. Configure Kestrel on the target sample server in the functional test to use only HTTP/2? Doesn't seem sensible, as nobody (sane) should run WebSockets on HTTP/2 😄.

Further technical details

• Latest master, commit 8841dac2a64b90a0eb6144f229885e832110bace
• Platform: Windows 10

[Tratcher]

Yup, by design. Note DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT was just removed from 5.0 in favor of a public API so we should be able to provide a better experience here: #282

[ManickaP]

This does not reproduce on 5.0.0-rc.1.20451.14 on which the current 5.0 tests run.
Problem is now isolated to netcoreapp3.1 target.

[ManickaP]

Since this doesn't reproduce on 5.0, I'm closing it. It's resolved by removal of the app switch/env variable.