-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Don't throw Exceptions from PipeWriter APIs after RST_STREAM #11675
Conversation
015382c
to
f283b35
Compare
By fixing the tests for this PR, I'm pretty sure I also accidentally fixed #7370. |
src/Servers/Kestrel/Core/src/Internal/Http/HttpResponsePipeWriter.cs
Outdated
Show resolved
Hide resolved
7f27446
to
785bb36
Compare
@@ -360,6 +410,25 @@ private async ValueTask<FlushResult> ProcessDataWrites() | |||
return flushResult; | |||
} | |||
|
|||
private Memory<byte> GetFakeMemory(int sizeHint) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should consider a shared output producer base class as there are now quite a few methods that are "shared".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's definitely some potential for better reuse. It could be a nice refactoring/cleanup down the road. I don't think it's critical for this change as this only duplicates a little more than we already were, and the logic that was copied is quite simple.
|
||
await Task.CompletedTask; | ||
writeEx = Assert.Throws<InvalidOperationException>(() => httpContext.Response.BodyWriter.GetMemory()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part confuses me. I thought we wanted to have the same behavior as streams where calling WriteAsync after Complete noops. However, I think the difference is that the noop behavior only occurs when the connection was aborted or the streams go away. Hence why you added the fake memory to HTTP2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want the same behavior as Streams where aborting http connection or http/2 stream makes writing no-op. If the application explicitly completes the PipeWriter, that a different story entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need an explicit test for not throwing an InvalidOperationException after abort?
@@ -35,7 +37,7 @@ public override void CancelPendingFlush() | |||
public override void Complete(Exception exception = null) | |||
{ | |||
ValidateState(); | |||
_pipeControl.Complete(exception); | |||
_completeTask = _pipeControl.CompleteAsync(exception); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sets us up for an inconsistent / confusing end-to-end story. Let's go over that before continuing here.
#7370 (comment)
785bb36
to
68b85c1
Compare
ae8cd9a
to
36ba5de
Compare
See https://github.com/dotnet/corefx/issues/38911#issuecomment-506574681