-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
QuicConnection.AcceptStreamAsync throws incorrect exception on browser close #60133
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsKestrel isn't getting the expected notification that the connection is closed by a browser. When the browser closes the connection (I'm simulating that by browsing to the website in Chrome, then closing the browser window), System.Net.Quic's From Kestrel's point of view of exceptions from AcceptStreamAsync:
Because Kestrel didn't abort the connection, and it is waiting for I believe the problem is in System.Net.Quic. Logs:
|
We should set up |
Status is a different thing from ErrorCode -- values for QUIC_STATUS are defined in msquic, while ErrorCode values are defined on application level. Same integer will mean different things, so I don't think that assigning Status value to ErrorCode is correct - the user who will receive QuicConnectionAbortedException may misinterpret the value. For 7.0 we should think this through -- add another field to the exception, or add another exception, or something else. For 6.0 though, when SHUTDOWN_INITIATED_BY_TRANSPORT is received, it should be enough to change connection's
Thoughts? |
Another option could be to throw a new exception, e.g. Updating Kestrel to catch a new error is simple enough (edit: as long as it is just from AcceptStreamAsync. If a new exception could throw from multiple places then I worry about catching them all). |
Does Kestrel also check for QuicOperationAbortedException vs QuicConnectionAbortedException for QuicStream operations? When a stream operation is aborted due to Connection being closed, one of there exceptions is thrown depending on who closed the connection. |
Yes. |
Then I would say changing Different exception is more logical, but more risky, since it requires more changes, in 2-3 places in Quic and 2-3 places in Kestrel + some worries whether we got all the places. |
Sure, I agree. |
Yes, I know. That's why I wrote 'We should set up
That's what I exactly meant, just this field to anything non -1 suffices ATM. |
@JamesNK Do I understand right that if you get |
There is an assumption in Kestrel that this error is only thrown from PR to fix that here: dotnet/aspnetcore#37432 |
Duplicate of #55157 |
Kestrel isn't getting the expected notification that the connection is closed by a browser.
When the browser closes the connection (I'm simulating that by browsing to the website in Chrome, then closing the browser window), System.Net.Quic's
QuicConnection.AcceptStreamAsync
is throwingQuicOperationAbortedException
. This is different from when HttpClient is disposed and closes the connection which isQuicConnectionAbortedException
.From Kestrel's point of view of exceptions from AcceptStreamAsync:
QuicOperationAbortedException
= the server closed/aborted the connectionQuicConnectionAbortedException
= the peer closed/aborted the connectionBecause Kestrel didn't abort the connection, and it is waiting for
QuicConnectionAbortedException
to indicate the peer closed the connection, the HTTP/3 connection stays open in a bad state.I believe the problem is in System.Net.Quic.
QuicConnection.AcceptStreamAsync
should throwQuicConnectionAbortedException
when a connection is closed by the browser.Logs:
The text was updated successfully, but these errors were encountered: