> In 1.7 we could raise a loud exception when stream_content=True and > response.content is accessed directly. Middleware can do nothing if they > don't care about or need to worry about streaming responses. If they are > capable of functioning with a streaming response, they can check > response.stream_content and wrap the content generator with `response.content > = wrap(response)`.
Rather than requiring stream-capable middleware to check if it is stream content, and also require them to handle non-stream content separately, can we have .stream_content return an auto created generator with some sane automatic divisions (at newlines or every x bytes/characters). This would allow stream-aware middleware to act as if everything they do is streams, even if in reality it is not. If we don't do this, it seems likely enough that middlewares that are stream-aware might end up doing this conversion anyway. If that's the case, moving that work into .stream_content can save them some common boilerplate code. One possible problem with this approach would be that if there are many middlewares, alternating back and forth between stream aware and stream unaware, that the overhead might be significant. If it turned out that was the case, then proper ordering of middlewares would be part of optimizing a project, if it isn't already. Ryan -- 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.
