-
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
WinHttpHandler: Read HTTP/2 trailing headers (replacement PR) #48704
WinHttpHandler: Read HTTP/2 trailing headers (replacement PR) #48704
Conversation
…' into winhttp/trailing-headers
Tagging subscribers to this area: @dotnet/ncl Issue DetailsFixes #44778, finalizing the work started in #46602. Notes from the original PR:
My additions to the original PR:
Notes on testing
/cc @JamesNK
|
@JamesNK do you plan to do some sort of end-to-end validation of dotnet/core#5713 or have you already done it with your prototype? |
I tested end-to-end with my earlier PR. Once this PR is merged I'll reference WinHttpHandler preview package off the .NET 6 feed and re-run the test. There is a copy of it here if you want to try it yourself. Replace the WinHttpHandler.dll file in the console's Lib directory. |
Is that is a common problem with all WinHttpHandler HTTP/2 tests on .NET Framework?
It does with .NET 5 + Windows 10 Build 20241 or later. |
src/libraries/System.Net.Http.WinHttpHandler/src/System/Net/Http/WinHttpTrailersHelper.cs
Show resolved
Hide resolved
src/libraries/System.Net.Http.WinHttpHandler/src/System/Net/Http/WinHttpTrailersHelper.cs
Outdated
Show resolved
Hide resolved
if (!isTrailingHeaders) | ||
{ | ||
Debug.Assert(lastError != Interop.WinHttp.ERROR_WINHTTP_HEADER_NOT_FOUND); | ||
|
||
if (lastError != Interop.WinHttp.ERROR_INSUFFICIENT_BUFFER) | ||
if (lastError != Interop.WinHttp.ERROR_INSUFFICIENT_BUFFER) | ||
{ | ||
throw WinHttpException.CreateExceptionUsingError(lastError, nameof(Interop.WinHttp.WinHttpQueryHeaders)); | ||
} | ||
} | ||
else | ||
{ | ||
throw WinHttpException.CreateExceptionUsingError(lastError, nameof(Interop.WinHttp.WinHttpQueryHeaders)); | ||
if (!(lastError == Interop.WinHttp.ERROR_INSUFFICIENT_BUFFER || lastError == Interop.WinHttp.ERROR_WINHTTP_HEADER_NOT_FOUND)) | ||
{ | ||
throw WinHttpException.CreateExceptionUsingError(lastError, nameof(Interop.WinHttp.WinHttpQueryHeaders)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this would be simpler as:
if (lastError != Interop.WinHttp.ERROR_INSUFFICIENT_BUFFER &&
(!isTrailingHeaders ||
lastError != Interop.WinHttp.ERROR_WINHTTP_HEADER_NOT_FOUND))
{
throw WinHttpException.CreateExceptionUsingError(lastError, nameof(Interop.WinHttp.WinHttpQueryHeaders));
}
or something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It also has to be preceded by:
Debug.Assert(isTrailingHeaders || lastError != Interop.WinHttp.ERROR_WINHTTP_HEADER_NOT_FOUND);
Can't decide if the code more readable in this form, pushed a change anyways.
src/libraries/System.Net.Http.WinHttpHandler/src/System/Net/Http/WinHttpResponseStream.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: James Newton-King <[email protected]>
…rsov/runtime into winhttp/trailing-headers
@JamesNK yes, I think it's a big gap, the following is a very common pattern to disable tests here: runtime/src/libraries/Common/tests/System/Net/Http/HttpClientHandlerTest.cs Lines 151 to 156 in 59417ef
The only way to overcome this is to use our shared remote endpoints (stuff under https://corefx-net-http2.azurewebsites.net/) instead of LoopbackServer.
Don't have much experience with Azure App Services, creating a website with a preview Windows build doesn't look like a trivial task to me. So I think we are stuck with local testing for now. |
There is an issue we need to look at before proceeding. Might be a local config issue or a bug in the Windows preview build I'm using (21320), but I'm concerned if it's something more serious. On my preview test machine, running This is also happening with the original #46602 branch. @JamesNK have you seen this on your preview test machine? @wfurt do those error messages ring any bells? |
I don’t know. It took me a while to setup the runtime solution and tests, I focused on just getting the new trailers tests working. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Outstanding test failures look unrelated. Confirm they're unrelated or fix.
HTTP/2 trailers changes LGTM.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
FYI
|
FYI opened tracking issue to document the feature: |
Fixes #44778, finalizing the work started in #46602.
Notes from the original PR:
HttpResponseMessage.TrailingHeaders
in netstandard2.1. With older targets the trailers are stashed inHttpRequestMessage.Properties
.Additions to the original PR:
>=19622
WINHTTP_OPTION_STREAM_ERROR_CODE
)Notes on testing
localhost
. It's not possible to host this service as an Azure App, because Azure can not bypass ISS, and Kestrel does not support Trailers with IIS. This is an unfortunate situation IMO, since we added this feature primarily for .NET Framework gRPC support, and looks like we will never be able to regression test it./cc @JamesNK