HTTP/3: Add IStreamAbortFeature

[JamesNK]

Fixes #31970
Fixes #33575

HTTP/3 streams support aborting individual sides of a connection stream. Feature is so HTTP layer can abort reading/writing in transport layer.

Args:

• errorCode is sent to the peer. long is used because it is variable length.
• Exception is used to complete transport pipes.

Example usage:

The client is uploading data to the server in an HTTP/3 request. The server completes RequestDelegate (i.e. user app code) without reading all of the data. HTTP/3 layer in the server will gracefully finish writing the response and abort reading the request. The abort tells the client it can stop uploading.

namespace Microsoft.AspNetCore.Connections.Features
{
    /// <summary>
    /// Supports aborting individual sides of a connection stream.
    /// </summary>
    public interface IStreamAbortFeature
    {
        /// <summary>
        /// Abort the read side of the connection stream.
        /// </summary>
        /// <param name="errorCode">The error code to send with the abort.</param>
        /// <param name="abortReason">An optional <see cref="ConnectionAbortedException"/> describing the reason to abort the read side of the connection stream.</param>
        void AbortRead(long errorCode, ConnectionAbortedException abortReason);

        /// <summary>
        /// Abort the write side of the connection stream.
        /// </summary>
        /// <param name="errorCode">The error code to send with the abort.</param>
        /// <param name="abortReason">An optional <see cref="ConnectionAbortedException"/> describing the reason to abort the write side of the connection stream.</param>
        void AbortWrite(long errorCode, ConnectionAbortedException abortReason);
    }
}

[JamesNK]

In HTTP/3 the read and write sides of the stream can be aborted independently. An error code is sent with these aborts.

I followed the pattern of ConnectionContext.Abort(ConnectionAbortedException abortReason) which uses the exception to pass in a reason. The reason isn't sent to the peer in HTTP/3 and is only used by logging. It can be removed if we don't think logging a reason in the transport adds value.

[JamesNK]

Do thumbs up mean keep the exception? 😄

Update: Ok, I see the point of passing exception in now. It is used with Input.Complete and Output.Complete.

[JamesNK]

@halter73 @Tratcher

[halter73]

If there's an active reader, can we throw this ConnectionAbortedException from the current read similar to what we do with SocketConnection?

[JamesNK]

I'll add a test and see what happens.

[halter73]

Does this effectively get logged twice now? I'm okay with it if it's different categories and they're both debug level. Just checking.

[JamesNK]

It's logged once at the HTTP layer and once and the transport layer.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.