Hello, While I'm working on HttpResponse, I'd like to resolve two related tickets. Here's my plan for discussion.
#6527 is about normalizing how HttpResponse deals with iterators. For more background, see part 1 of the first email of this thread. Let's take an HttpResponse instantiated with an iterator. It's possible not to access the content until the WSGI server iterates on the response. This allows creating streaming responses in Django 1.4. But it's incompatible with most middleware. Most often middleware will access the content before the response is finally rendered. The first access to response.content works, but subsequent accesses return an empty string. The fix is easy: consume the content of the iterator and save it in a list for further use. This can be done at two points: a) In __init__. This is a simple solution advocated by Malcolm in several tickets and it decreases the complexity of HttpResponse (a worthy goal). It's backwards incompatible because it breaks the streaming scenario described above. We'd have to raise a deprecation warning when the iterator is consumed before the final iteration by the WSGI server, tell people to use StreamingHttpResponse instead, and make the change after two releases. b) When required. This is the solution implemented in this patch: https://code.djangoproject.com/attachment/ticket/6527/6527-v3.patch Even if the target is a), this is a useful workaround for the length of the deprecation period. #18796 is about converting the content of an HttpResponse to bytes. I believe the result should be identical when accessing response.content / response.streaming_content and when iterating on the response. Currently this isn't guaranteed (for historical reasons for .content, by my fault for .streaming_content). This becomes easier once #6527 is fixed, because we know exactly where to apply the conversion in HttpResponse: in the method that consumes the iterator, and in __next__. This translates easily to StreamingHttpResponse. The conversion function: - must accept text and bytes as input; - historically accepts integers, and some tests rely on this; I can't figure out under which real-life circumstances this would be useful, but it doesn't really hurt either; - must deal with encoding "appropriately". This is also the topic on #10190. I have to work on that third point. There's encoding information available both in self._charset and in the Content-Encoding header. When force_bytes is called on a bytes object with a charset other than utf-8, it will decode the bytes as utf-8 and re-encode them with the provided charset. Is this appropriate? I'll probably write down all the combinations of input type and encoding information, and determine what the output should be in each case. In practice everyone must be using utf-8 everywhere anyway… Finally, I've closed five or six other tickets that were fixed at the same time as #7581 or didn't add anything to the two tickets described above; please tell me if I've missed something. Thanks, -- 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.
