-
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] The server returned an invalid or unrecognized response. #55988
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsI have a gRPC call that uses HTTP/3 and it is erroring because of the response. I tried to figure out why HttpClient is rejecting the response so I enabled Kestrel connection logging and client event source. This seems to be the specific problem:
Complete logs below. As far as I can tell Kestrel is sending a HEADERS frame and HttpClient seems to have a problem reading it. I don't know if that is because Kestrel is doing something wrong or HttpClient is.
Repo: https://github.com/JamesNK/grpc-dotnet/tree/jamesnk/http3-badresponse
|
Triage: Looks pretty bad, we should root cause, then decide what to do about it. |
Triage: 100% repro on this type of request. |
I looked into this more and have narrowed down the cause to the status code.
endpoints.MapPost("/ThisIsATest", context =>
{
context.Response.StatusCode = 415;
return Task.CompletedTask;
}); Success for 200: endpoints.MapPost("/ThisIsATest", context =>
{
context.Response.StatusCode = 200;
return Task.CompletedTask;
}); The question is, is there a bug in how Kestrel writes the status code, or a bug in how HttpClient reads it? |
If we get hands on session keys and/or sever key and if we can collect packecpature we should be able to peak in, right? |
I'm pretty sure the problem is in HttpClient. I tested Kestrel with curl + http3. curl recognises the 415 status.
I think you need to add some tests of HttpClient loading HTTP/3 responses with 415 statuses to find out what is going on. The error may be happening because the 415 status isn't in the static table, unlike 200 and other common statuses. |
Triage: we should support static QPACK, we should be sure we support other than well-defined status codes in QPACK. |
It is a bug in our QPACK code (so it was not Kestrel sending 100, but us misinterpreting "Literal Field Line With Name Reference" path). I will put up a PR with a fix tomorrow. |
Fix "Literal Header Field With Name Reference" parsing for Status code. Add tests for QPACK-ed and not QPACK-ed status receiving for all status codes (except informational). Fix QPackStaticTable.HeaderLookup to comply with spec (the order was off, so lookup didn't work correctly in some cases). Fixes #55988
I have a gRPC call that uses HTTP/3 and it is erroring because of the response.
I tried to figure out why HttpClient is rejecting the response so I enabled Kestrel connection logging and client event source. This seems to be the specific problem:
Complete logs below. As far as I can tell Kestrel is sending a HEADERS frame and HttpClient seems to have a problem reading it. I don't know if that is because Kestrel is doing something wrong or HttpClient is.
Repo: https://github.com/JamesNK/grpc-dotnet/tree/jamesnk/http3-badresponse
Test: AuthTests.SendUnauthenticatedRequest_UnauthenticatedErrorResponse (Note this type is parameterized. Need to run
Http3WithTls
)The text was updated successfully, but these errors were encountered: