Fix graceful shutdown of connection close in HTTP/3 #26638
Conversation
ghost
added
the
|
@JamesNK this has the settings commit in it as well, as an FYI. |
|
Add a unit test/functional test of stopping a HTTP/3 connection? |
jkotalik
force-pushed
the
jkotalik/funWithHttp3
branch
from
2ec0c43 to
e3e7c7a
Compare
|
Found a small thing I want to resolve from runtime before merging dotnet/runtime#44885 |
jkotalik
force-pushed
the
jkotalik/funWithHttp3
branch
from
59d31eb to
5cc3855
Compare
| { | ||
| Assert.True(buffer.Length > 0); | ||
|
|
||
| if (Http3FrameReader.TryReadFrame(ref buffer, frame, maxFrameSize, out var framePayload)) |
There was a problem hiding this comment.
I looked in Http3FrameReader to see what it did with maxFrameSize, and it looks unused. Is there a maximum frame size in HTTP/3?
The reason I started looking into this is to see how header continuation frames were handled, but they don't seem to be a thing in HTTP/3.
There was a problem hiding this comment.
I don't think there is a maximum frame size in HTTP/3, but a peer may enforce one for headers via a HTTP/3 setting: https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-4.1.1.3.
So I think maxFrameSize should somehow only apply to headers.
jkotalik
force-pushed
the
jkotalik/funWithHttp3
branch
from
df2af5f to
d0b725f
Compare
|
Filed #29034 as a follow up |
amcasey
added
area-networking
Right now, if you CTRL+C when a connection is still active in HTTP/3, the connection will not gracefully shutdown. This is because we never have anything that interrupts the loop accepting new streams for a connection.
This change adds a CTS which is canceled in abort and StopProcessingNextRequest, which causes the Accept loop to exit.
This change also tries to centralize access to the stream dictionary, which ends/aborts all streams. Instead of aborting all streams inside of the InnerAbort, we check state in the finally block of the accept loop. Things are locked, so it should be all fine and dandy.