IIS HTTP/2 Response Trailers

[jkotalik]

Adds support for IIS Response Trailers. cc @pgovind @GrabYourPitchforks @Tratcher

Noteworthy:

• Feature detection is done through the IIS call to HttpGetExtendedInterface (no need to check windows versions)
• I don't think we have a queue to run these tests.
• Not supporting Http/1.1 chunked trailers

[pgovind]

Just a minor comment in the unit tests. Otherwise LGTM!

[Pilchie]

See https://github.com/dotnet/aspnetcore-internal/issues/3170 for details of bringing up new queues. I believe with have 20H1 builds now, but I think this still needs something even newer?

[Tratcher]

When is the reader completed? Is it always after the request pipeline exits? Or can CompleteAsync make it complete early?

[jkotalik]

The reader is completed after the request pipeline exits: https://github.com/dotnet/aspnetcore/blob/master/src/Servers/IIS/IIS/src/Core/IISHttpContextOfT.cs#L93. It can also be completed due to client disconnect or Abort.

CompleteAsync currently doesn't make it complete early: https://github.com/dotnet/aspnetcore/blob/master/src/Servers/IIS/IIS/src/Core/IISHttpContext.FeatureCollection.cs

[jkotalik]

Writing skip conditions will be hard, I somehow need to know if the iiscore.dll is updated to a new enough version...

[Tratcher]

Writing skip conditions will be hard, I somehow need to know if the iiscore.dll is updated to a new enough version...

Wouldn't that be in sync with the OS version? We have skips for that.

[jkotalik]

Wouldn't that be in sync with the OS version? We have skips for that.

Yeah, that would work. I think I need to skip entirely for now as there isn't a version of windows that has that yet.

[JamesNK]

Please add a test that combines trailers with CompleteAsync.

Check that CompleteAsync immediately sends trailers to the client and ends the response while the request delegate is still running.

[Tratcher]

Those are the tests we had to remove, CompleteAsync doesn't work in IIS's request lifetime model. Is that going to be a problem? Maybe for the streaming error case?

[JamesNK]

CompleteAsync is used with the deadline timeout. When the timeout is reached the timer calls CompleteAsync to send trailing HEADERS frame, then sends RST_STREAM frame with either IHttpResetFeature/HttpContext.Abort.

What will happen in IIS?

[Tratcher]

The reset will probably happen first and prevent the trailers from being sent.

[Tratcher]

FYI Justin is implementing reset now so we should be able to verify that.

[JamesNK]

Will the reset/abort happen immediately (by which I mean will the server send RST_STREAM straight away) or will it wait for the request delegate to complete?

Would properly supporting CompleteAsync require changes in IIS? How big a change would it be?

Does HttpSys properly support CompleteAsync?

[Tratcher]

HttpSys does properly support CompleteAsync.

Justin has some ideas for how to implement CompleteAsync in IIS. There's a related issue over at #17268. I think it can be done without changes to IIS, but it would require a lot of hardening to AspNetCore to avoid touching any native IIS structures after CompletAsync.

[JamesNK]

Ok! To give you an idea of what the impact on gRPC would be:

If CompleteAsync isn't supported correctly, and the server doesn't send trailers to the client, there is a chance that gRPC calls that exceed the deadline timeout will fail with the wrong status code. I say chance because there is always a race between the client and server to report the exceeded deadline. If the client wins then the right status will be reported, if the server wins then the wrong status will be reported.

This wouldn't be disastrous to gRPC support on IIS for 5.0, but it would be a known issue that would have to be called out. And we'd want to try to fix it in the future.

[jkotalik]

Updated based on latest changes from IIS layer.