Closed pakrym closed 8 years ago
By design, call Flush/Async.
Then why have it? Flush works even without DisableResponseBuffering
Only on Core, not on Net 4.5.1.
I'm concerned that it's not consistent with ResponseBuffering in buffering if you call DisableResponseBuffering
writes are immediately written to the wire.
@davidfowl
It's pretty strange that the same interface has different behavior depending on who implements it. Wouldn't it be better to make them all consistently disable all buffering all the time when this method is called?
Are you saying that because that's the name of the feature, or because that's the behavior end-users actually want? When I had this discussion with @DamianEdwards his primary concern was that we make Flush work.
The current implementation is a compromise that allows both compression and the ability to Flush, if supported.
Because the contract of the interface says get all buffering out of the way. An explicit flush shouldn't be required to make this work. Flushing without calling disable buffering can do this can't it?
Not on Net451
Offline discussion: DisableResponseBuffering should disable compression on .NET 4.5.1 and auto-flush writes on .NET Core.
Writes would not flush automatically in the following code.
@Tratcher