Hi Gavin,
The whole point of the HttpStreamingResponse API to access the content is to be
incompatible with HttpResponse. Otherwise it's too easy to consume streamed
content accidentally.
Re-introducing a common API ("streaming_content") would remove that benefit, it
would be confusing in the non-streamed case, and it would certainly be misused
("yes I just used ''.join(streamed_content), isn't that the canonical way to
access response content in all cases?").
The incompatible API is a hint that you must think about what you're doing when
you're writing streaming-aware middleware, and specifically, that you mustn't
consume the iterator.
Your goal is interesting but it seems optimistic to me. Out of the four
examples you gave, two are very hard to implement correctly for streaming
responses.
> - GzipMiddleware (compress_string(x) == compress_sequence([x]))
This one is implemented by Django. If you look at the code, you'll see it's
reasonable to use a different implementation for the streamed and not-streamed
cases.
> - StripWhitespaceMiddleware
For this one, the pattern would be:
if response.streaming:
response.streaming_content = itertools.imap(strip_whitespace,
response.streaming_content)
else:
response.content = strip_whitespace(response.content)
Yes, this is a bit of boilerplate. I'd like to reduce it, but not at the cost
of giving a streaming_content attribute to regular responses; it's too
confusing. You can probably abstract the pattern in a response middleware base
class. That works only when the "transform" function can be applied to any
subset of the content. I don't expect many useful middleware to fall in this
category
> - ContentDoctorMiddleware (https://github.com/unomena/django-content-doctor)
This won't work on streaming responses without consuming the content, because a
match for the regex may overlap a boundary between response chunks.
> - A hypothetical middleware that appends debug information to the end
> of the response. debug-toolbar may be able to work like this.
Looking for the </body> boils down to the same problem as above, and can't be
implemented without consuming the content for the same reason.
--
Aymeric.
--
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.
