-
Notifications
You must be signed in to change notification settings - Fork 2.1k
ContentResult forcing chunked encoding #4876
Comments
DisableResponseBuffering doesn't have any affect in a default app, Kestrel doesn't implement it. |
BTW here's why we added it: #3016 |
ContentResult should still set Content-Length. |
Ah ok so not a dupe, but we want to do both. |
Wondering if we need to do #4766 ...Having it doesn't hurt anything and also why have the |
You're using an undefined feature for an undefined benefit. If the user wants buffering, who are you to second guess them? |
Tratcher is right - "If the user wants buffering, who are you to second guess them?" - in this case the application was configured with response buffering for a reason, and the ContentResult was unexpectedly counteracting that choice. I'll add a note to #4766 also. I do like that the feature exists, and that it is implemented by the ResponseBufferingMiddleware.cs, but it shouldn't be used unless there's a specific functional reason an action doesn't work with buffering enabled. Signalr server-sent events would be the only case I can think of. The mvc action results should only set the content length if known, writeasync the bytes, but not call flush or disable buffering because that messes with the response handling. |
It looks like the ContentResult is disabling response buffering in order to skip the memory allocation. But it's not setting the content length before doing the write, so it's forcing the result to be chunked. Would be much better to encode to buffer pooled bytes and set the content length before doing the write from bytes.
https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Core/ContentResult.cs#L71
Returning an ObjectResult of the string as a workaround gives the desired effect - the response buffering middleware
return "OK"
comes back with Content-Length: 2The text was updated successfully, but these errors were encountered: