Malcolm Tredinnick wrote: > The response should just return a copy of the > content when response.content is accessed, which means turning any > iterator into a proper string.
Ouch.. I thought it already does just that. Yeah, it's a bug then. Though simple to fix. > But it *does* require that everybody will have to behave this way. If I > am writing a piece of middleware I have to assume the worst case, which > here means that the content is a non-repeatable generator. Now I understand what you don't like. If we simply make HttpResponse to replace its source generator with a string upon exhaustion, the problem will disappear. But it's another bug. I'm talking here along the lines "why don't we make GzipMiddleware not read response.content if it doesn't have to". > It's not something that cannot wait and be > trialled in various approaches after 1.0 Oh, yes, definitely post-1.0. > The > ticket itself already proposes some things that will lead to bugs: for > example, content-length must *always* be set I was thinking about it myself... But don't things like Comet work with infinitely long responses that don't have content length? --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
