I'm in agreement with Tai. Keeping them separate gives them consistent behavior for view authors to expect.
"One thing I'm curious about here is the HTTP Content-Length header. It's late and I'm tired and cranky, so I may have missed it, but outside of the infrastructure for runserver I can't find any place where Django reliably sets it on outgoing responses." This is the case, yes, if the HTTP and GZip middleware are not used. We had to modify both of those to make sure they didn't consume the content generator to find the Content-Length. I imagine, IF we wanted to, setting the Content-Length header could be done in the base handler. One thing I am not certain about (I am about to head out the door) is if it isn't set BECAUSE the middleware can modify it. If so, then it would certainly have to be set after the response middleware were applied. On Aug 14, 4:07 am, Tai Lee <[email protected]> wrote: > I think I prefer keeping HttpResponse and HttpResponseStreaming > separate. Using the latter indicates explicitly that the user wants to > send a streaming response and disable any middleware that doesn't > explicitly support it. Using the former should always consume any > content passed to it so that middleware doesn't have to know or care > what type of content was passed to the HttpResponse. > > This way only specific middleware are required to opt-in to support > streaming responses, rather than requiring all middleware to > repetitively examine the content type and opt-out to avoid breaking > streaming responses. > > It also keeps the interface simple. HttpResponse.content will always > be a string, HttpResponseStreaming.content will always be an iterator, > and HttpResponse classes will only need to expose one attribute for > content either way. > > And it's more explicit. Django will only disable middleware that > doesn't explicitly assert that it works with HttpResponseStreaming, > and only when the user explicitly creates an HttpResponseStreaming > object. > > Regarding `hasattr` vs `isinstance`, the latter should also work with > subclasses and has the benefit of detecting only HttpResponseStreaming > (and derivative) objects, not just any object with a > `content_generator` attribute. If we use `isinstance`, the > HttpResponseStreaming class won't even need a `content_generator` > attribute, nor will middleware need to poke around in it's internals > to replace the content with a new generator. > > Regarding the Content-Length header, HttpResponse should always set it > because the content will always be a string, but HttpResponseStreaming > should never set it because we can never know the length without > consuming the content. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
