On 23 elo, 15:51, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > My current feeling about the options is that this is getting > complex... So, as-simple-as-can-be solution: > - Add a flag to the response which tells if the response is > streaming or not. You can set this in response's.__init__. We might be > able to set this to True by default if the content is generator based > (can we autodetect this reliably?). > - Cache the .content on first access if the content is generator > based. No matter if the response is flagged as streaming or not. > - Update middlewares that need to skip streaming responses to check > for the flag.
I re-read the original ticket, and this is pretty much Tai Lee's proposed solution in the ticket. My understanding is that by doing the above we will not break anything, but will make it at least possible to use streaming responses with certain middleware. So, we gain something, but lose nothing. Middleware which do not access content do not need changes. Middleware which access content will continue to work, but will break streaming responses. They do that now, too, possibly silently corrupting the response (ConditionalGetMiddleware for example). In addition, it is possible to update content accessing middleware to do the right thing for streaming responses. We might additionally add capabilities based middleware API, or a way to include/exclude middlewares based on various conditions. These seem hard to design. The problem has been there for 4+ years, so maybe it is time to apply this simple solution? - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. 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.
