Skip to content
This repository was archived by the owner on Dec 14, 2018. It is now read-only.

ContentResult forcing chunked encoding #4876

Closed
lodejard opened this issue Jun 17, 2016 · 9 comments
Closed

ContentResult forcing chunked encoding #4876

lodejard opened this issue Jun 17, 2016 · 9 comments
Assignees

Comments

@lodejard
Copy link
Contributor

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: 2

@Eilon Eilon added this to the 1.1.0 milestone Jul 8, 2016
@Eilon
Copy link
Member

Eilon commented Jul 8, 2016

Sounds legit to me. @kichalla please consult with @rynowak and @Tratcher as needed.

@Tratcher
Copy link
Member

Tratcher commented Jul 8, 2016

DisableResponseBuffering doesn't have any affect in a default app, Kestrel doesn't implement it.

@Eilon
Copy link
Member

Eilon commented Jul 8, 2016

BTW here's why we added it: #3016

@Eilon
Copy link
Member

Eilon commented Jul 8, 2016

And this is why this sounded familiar: #4766

Remove disable buffering feature from our action result classes

Perhaps we can close this bug as a dup of #4766?

@Tratcher
Copy link
Member

Tratcher commented Jul 8, 2016

ContentResult should still set Content-Length.

@Eilon
Copy link
Member

Eilon commented Jul 8, 2016

Ah ok so not a dupe, but we want to do both.

@kichalla
Copy link
Member

kichalla commented Jul 8, 2016

Wondering if we need to do #4766 ...Having it doesn't hurt anything and also why have the IHttpBufferingFeature if its not supported yet.

@Tratcher
Copy link
Member

Tratcher commented Jul 8, 2016

You're using an undefined feature for an undefined benefit. If the user wants buffering, who are you to second guess them?

@lodejard
Copy link
Contributor Author

lodejard commented Jul 8, 2016

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.

https://github.com/aspnet/BasicMiddleware/blob/dev/src/Microsoft.AspNetCore.Buffering/ResponseBufferingMiddleware.cs

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants