Today, if you call ResponseBodyPipe.GetMemory() to start writing the response body without first calling IHttpResponseStartFeature.StartAsync(), GetMemory() will throw on Kestrel because the possibly-async response OnStarting callbacks haven't gotten the chance to run and we don't want to block in GetMemory() to wait for them.
Instead, we should make the behavior more forgiving by having GetMemory() return memory leased directly from the memory pool instead of the response body PipeWriter. This would continue until the first call to FlushAsync(). At that point, the OnStarting callbacks would be called, the headers would be committed, and the data written to the memory leased directly to the pool would be copied to the response body PipeWriter.
This way, calling IHttpResponseStartFeature.StartAsync() improves efficiency by avoiding copies before the first flush, but not calling StartAsync() doesn't break the app.
@davidfowl @jkotalik @Tratcher @muratg
Today, if you call ResponseBodyPipe.GetMemory() to start writing the response body without first calling IHttpResponseStartFeature.StartAsync(), GetMemory() will throw on Kestrel because the possibly-async response OnStarting callbacks haven't gotten the chance to run and we don't want to block in GetMemory() to wait for them.
Instead, we should make the behavior more forgiving by having GetMemory() return memory leased directly from the memory pool instead of the response body PipeWriter. This would continue until the first call to FlushAsync(). At that point, the OnStarting callbacks would be called, the headers would be committed, and the data written to the memory leased directly to the pool would be copied to the response body PipeWriter.
This way, calling IHttpResponseStartFeature.StartAsync() improves efficiency by avoiding copies before the first flush, but not calling StartAsync() doesn't break the app.
@davidfowl @jkotalik @Tratcher @muratg