HTTP/3: Support aborting one direction of a stream

[JamesNK]

QUIC supports aborting one direction of a stream. For example:

https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-4.1-15

A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When the server does not need to receive the remainder of the request, it MAY abort reading the request stream, send a complete response, and cleanly close the sending part of the stream. The error code H3_NO_ERROR SHOULD be used when requesting that the client stop sending on the request stream.

System.Net.Quic is adding QuicStream.Abort(int protocolError, QuicAbortDirection direction);

In our abstractions we have a ConnectionContext.Abort(ConnectionAbortedException abortReason); method.

We could add an abort overload on ConnectionContext. Another option is to specify the direction like we are with the error code, using a feature. Like there is IProtocolErrorCodeFeature, we could add an IProtocolErrorDirectionFeature.

@halter73 @Tratcher @davidfowl

[Tratcher]

it MAY abort reading the request stream, send a complete response, and cleanly close the sending part of the stream

Is the ordering there significant? We do this today for http/2, but we send the response first, close the response, and then reset the stream. I don't think we'd usually have the forknowledge to know the request needed to be aborted when we started sending the response.

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[JamesNK]

it MAY abort reading the request stream, send a complete response, and cleanly close the sending part of the stream

Is the ordering there significant? We do this today for http/2, but we send the response first, close the response, and then reset the stream. I don't think we'd usually have the forknowledge to know the request needed to be aborted when we started sending the response.

I don't know whether the ordering is significant.

Because we're operating in the HTTP/3 layer we don't know when the QUIC layer has finished. Calling Transport.Output.Complete instructs the transport to completing writes, there there is no way to know when it will be done.

And we can't embed logic into the QUIC transport to make it automatically abort reads if writes are finished, because this is HTTP/3 logic. A different QUIC app might use it differently.

For these reasons, I think we need a way to be able to specify from the HTTP/3 layer that one side of the stream should be aborted.

[Tratcher]

Reading more, Http/2 and 3 aren't quite equivalent here. For HTTP/2 a reset is not directional, a reset sent by either party fully aborts the stream in both directions, hence you need to send the complete response before sending the resetting the request.

Quic defines the STOP_SENDING frame to abort the receiving stream, and the RESET_STREAM frame to abort the sending stream. With that separation it would be possible to abort the sending stream first and still successfully complete the response. We would want an API to target these separately.