-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Fix TestServer from blocking on request stream #15591
Conversation
Do it in 5.0 then backport to 3.1? |
Which custom HttpContent implementations? It sounds like the content objects are at fault here. I'm not sure why you're changing the server to accommodate them. |
Forward is easier than backwards. |
Sorta but not really. It's much more complicated to implement this in each HttpContent. See https://github.com/dotnet/corefx/blob/26d7b6626ab0385a1158e674855f81ab73f628e0/src/System.Net.Http/src/System/Net/Http/HttpContent.cs#L453 I had the same impression at first but it's far easier to make this work in TestServer than it is to fix the HttpContent implementation (just like we auto-rewind your Stream, though I don't, agree with that one).
But then we can't merge it until it goes through the layers of approval. But whatever works I guess. |
No TestServer is at fault for using Should the gRPC content fix itself so ReadAsStreamAsync is supported without blocking? Maybe. But that's a separate issue. |
Related question in HttpClient-side - https://github.com/dotnet/corefx/issues/42160 |
Content that expect to stream really should implement CreateContentReadStreamAsync and then you wouldn't have to change anything in TestServer, no? |
This change to TestServer is fine |
Also, looking for review approvals // @davidfowl, @Tratcher |
TestServer is a pretty low-risk area. I'm in favor for 3.1. It's @Pilchie 's final call though. |
b4a7f55
to
2ee8f82
Compare
🆙 📅 |
What is the scenario for |
It's for testing only. Using it in a production is not supported. It doesn't ship in any shared framework. Essentially it's an in-memory test server. You can point it at your app setup (middlewares, services, etc.) and it will start up a fake "app" and give you an |
People use it in Azure functions to bootstrap ASP.NET Core on top of Azure functions. |
configureContext(_httpContext, _requestPipe.Reader); | ||
} | ||
|
||
internal void SendRequestStream(Func<PipeWriter, Task> sendRequestStream) |
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.
The layering still seems odd here. Only ClientHandler needs/uses the request body pipe and _sendRequestStreamTask, why doesn't it own those? What it needs from HttpContextBuilder is a callback for CompleteRequestAsync and/or cancel.
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.
I did it this way because the alternative is callbacks everywhere:
- After request is complete
- Request is aborted from server
- Request is aborted from client
Sure HttpContextBuilder owns the request pipe and task, but using it is optional.
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.
Yea I don’t think this layering is super important
Ok, Approved for 3.1.0-Preview3. |
Is there any more feedback/changes required here? |
Fixes #15415
HttpContent.ReadAsStreamAsync()
will block when called in customHttpContent
implementations. CallingHttpContent.CopyToAsync(stream)
mirrors whatHttpClient
does more closely.Note, this PR is on 3.1. The bug blocks people from using TestServer with gRPC. Would be nice to unblock before 5.0. @anurse is this your call? Need anymore info?