It sounds like the preferred solution is still "don't do that", which I think corresponds most closely with option 1. Simply consuming generator content in `HttpResponse.__init__()` in all cases would prevent some of the surprising behaviour we are seeing, but it would completely break any support for streaming responses.
I thought that Jacob's "It's clear to me that we have to do *something* about this" comment when he marked #7581 as "accepted" would take "don't do that" off the table. > It might not count as a "backwards incompatible" change to revoke all support for streaming responses, as I couldn't find explicit support for them mentioned in the docs, but streaming responses have been around for a long time and people are relying on on this behaviour, as evidenced by several tickets and reported use cases (not limited to "large" responses, but also including "long running" responses). Those people just have to avoid some core middleware that currently break streaming responses by prematurely consuming content, and Django doesn't provide a generic or documented way for people to hook into this part of the framework on a per-response basis. They just have to choose "all or nothing" when it comes to those middleware, unless they also have control over the middleware (which they don't for core, contrib and third party middleware). I don't see a huge difference between wrapping or replacing the content of response, compared to wrapping or replacing the entire response. The key issue (for me) still remains, being that middleware would still have no way to know when it is appropriate for them to wrap or replace the entire response. It may also cause new complications with headers or properties of the wrapped response not being preserved. Removing `HttpResponse.content` entirely is probably a non-starter, as it would be a backwards incompatible change. It has been part of the public API since at least 1.0. Could somebody please explain their primary objections to option 2? This has a working up-to-date implementation already (just missing tests and docs, which I would be happy to contribute), is backwards compatible, fixes buggy behaviour in the general case where iterators are passed to `HttpResponse` as content but the developer does not explicitly want a streaming response, and it provides a hook for developers to explicitly tell middleware that the response should be streamed with `HttpResponse(stream_content=True)`. I've seen it asked, but not answered yet (unless I missed it), if there is really a need for more fine grained control than "is it streaming, or not?" (e.g. a capabilities based API on responses). If not, I think this is currently the most likely candidate for inclusion. Thanks. Tai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/F5cUHy1oOnsJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
