[HTTP/3] Test failure SendAsync_WithZeroLengthHeaderName_Throws #56292

Activity

1. karelz

   added

   area-System.Net.Http

   on Jul 26, 2021
2. karelz

   added this to the 6.0.0 milestone on Jul 26, 2021
4. ghost added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Jul 26, 2021
5. karelz

   added

   test-run-coreTest failures in .NET Core test runsTest failures in .NET Core test runs

   and removed

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Jul 26, 2021
6. karelz

   added 2 commits that reference this issue on Jul 27, 2021

   Disable test SendAsync_WithZeroLengthHeaderName_Throws

   ...

   c83f12b

   Disable test SendAsync_WithZeroLengthHeaderName_Throws (#56363)

   ...

   f32b55f
7. karelz

   added

   disabled-testThe test is disabled in source code against the issueThe test is disabled in source code against the issue

   on Jul 27, 2021
8. wfurt commented on Jul 28, 2021

   

   wfurt

   on Jul 28, 2021

   Member

   More actions

   This is easy to reproduce. The test actually expects failure e.g. IOException.
   The problem is that we throw

         System.Net.Quic.QuicConnectionAbortedException : Connection aborted by peer (256).
   

   My initial reaction was to add it to expected exceptions. But that seems wrong since Quic is not public so there would be no way for users to catch it.

   It seems like the right action would be to catch all Quic exceptions and convert them to either HttpRequest or IOExceptions. Thoughts on this @geoffkizer @stephentoub ?
9. stephentoub commented on Jul 28, 2021

   

   stephentoub

   on Jul 28, 2021

   Member

   More actions

   so there would be no way for users to catch it

   They can still catch it, just as the base Exception.

   In what situation do these exceptions escape unwrapped to the caller? From HttpClient we typically expect all exceptions to be wrapped in an HttpRequestException, or if coming out of a Stream, in an IOException.
10. wfurt commented on Jul 28, 2021

    

    wfurt

    on Jul 28, 2021

    Member

    More actions

    Looking at it again, it actually escapes at server side e.g. loopback

            --- End of stack trace from previous location ---
            /home/furt/github/wfurt-runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs(581,0): at System.Net.Quic.Implementations.MsQuic.MsQuicStream.ShutdownCompleted(CancellationToken cancellationToken)
            /home/furt/github/wfurt-runtime/src/libraries/Common/tests/System/Net/Http/Http3LoopbackStream.cs(277,0): at System.Net.Test.Common.Http3LoopbackStream.SendResponseBodyAsync(Byte[] content, Boolean isFinal)
            /home/furt/github/wfurt-runtime/src/libraries/Common/tests/System/Net/Http/Http3LoopbackStream.cs(240,0): at System.Net.Test.Common.Http3LoopbackStream.SendResponseAsync(HttpStatusCode statusCode, IList`1 headers, String content, Boolean isFinal)
            /home/furt/github/wfurt-runtime/src/libraries/Common/tests/System/Net/Http/Http3LoopbackConnection.cs(190,0): at System.Net.Test.Common.Http3LoopbackConnection.HandleRequestAsync(HttpStatusCode statusCode, IList`1 headers, String content)
            /home/furt/github/wfurt-runtime/src/libraries/Common/tests/System/Net/Http/Http3LoopbackServer.cs(75,0): at System.Net.Test.Common.Http3LoopbackServer.HandleRequestAsync(HttpStatusCode statusCode, IList`1 headers, String content)
            /home/furt/github/wfurt-runtime/src/libraries/System.Net.Http/tests/FunctionalTests/HttpClientHandlerTest.Headers.cs(427,0): at System.Net.Http.Functional.Tests.HttpClientHandlerTest_Headers.<>c.<<SendAsync_WithZeroLengthHeaderName_Throws>b__16_1>d.MoveNext()
            --- End of stack trace from previous location ---
    

                   async server =>
                    {
                        // The client may detect the bad header and close the connection before we are done sending the response.
                        // So, eat any IOException that occurs here.
                        try
                        {
                            await server.HandleRequestAsync(headers: new[]
                            {
                                new HttpHeaderData("", "foo")
                            });
                        }
                        catch (IOException) { }
                    });

    So I guess less pressing but what the fix should be? Should Http3 loopback wrap or should we add the alternative Quic exceptions to tests as we see fit?

    I'll keep eyes on the client side. I just go to moving up from Quic to focusing on HTTP tests.
11. wfurt

    self-assigned this

    on Jul 29, 2021
12. ghost added

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Aug 3, 2021
13. wfurt

    closed this as completedin #56785on Aug 5, 2021
14. ghost removed

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Aug 5, 2021
15. ghost locked as resolved and limited conversation to collaborators on Sep 7, 2021