-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HTTP/3] Test failure SendAsync_WithZeroLengthHeaderName_Throws #56292
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsFailures 5/26-7/26 (incl. PRs):
Test type: System.Net.Http.Functional.Tests.SocketsHttpHandlerTest_HttpClientHandlerTest_Headers_Http3_MsQuic Failure:
|
Test: System.Net.Http.Functional.Tests.SocketsHttpHandlerTest_HttpClientHandlerTest_Headers_Http3_MsQuic.SendAsync_WithZeroLengthHeaderName_Throws Disabled test tracked by #56292
Test: System.Net.Http.Functional.Tests.SocketsHttpHandlerTest_HttpClientHandlerTest_Headers_Http3_MsQuic.SendAsync_WithZeroLengthHeaderName_Throws Disabled test tracked by #56292
This is easy to reproduce. The test actually expects failure e.g. IOException.
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 ? |
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. |
Looking at it again, it actually escapes at server side e.g. loopback
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. |
Failures 5/26-7/27 (incl. PRs):
Test type: System.Net.Http.Functional.Tests.SocketsHttpHandlerTest_HttpClientHandlerTest_Headers_Http3_MsQuic
Failure:
The text was updated successfully, but these errors were encountered: