On Tue, 2008-07-01 at 00:03 -0700, Tai Lee wrote: > http://code.djangoproject.com/ticket/7581 > > Just posted this ticket with an initial patch (sans documentation > changes and tests). Basically there are several middleware classes > that access HttpResponse.content directly which break streaming > HttpResponse objects that use a generator to yield content > progressively. > > I'd like to get some feedback on the direction and implementation of > the patch and proposed solution before I go any further with tests or > documentation changes.
I don't think we should be supporting on-demand generation like this. Go back a year or 18 months in the archives and look at where Brian Harring put up some patches to do that sort of thing. He and I and others spent ages chasing down unintended side-effects and in the end it was considered not worth it. That was tip-of-the-iceberg stuff. Yes, it's probably possible to get it right, but I'm not convinced it's worth it. It's quite a large restriction to say that no middleware should ever try to examine the contents of the HttpResponse since it might be an iterator that shouldn't be consumed. You're proposing a bunch of specific changes for the middleware we have now to work around that, but you're also imposing a huge functionality constraint on any future middleware (all middleware will have to work with the possibility that a non-consumable generator is there). You're also effectively said that only certain content types can be streamed (because a whole bunch of them *will* be affected by consuming middleware). "Just say no" is a cleaner solution here. I thought we'd fixed it, but apparently we haven't: if any iterator is passed into an HttpResponse, it should be converted to a string immediately so that things can index into it without doing non-repeatable consumption. The only thing that might be worth doing in this are is adding a way to say "middleware should never be called on this response" and then somebody can write their own HttpResponse subclass and be in complete control of their destiny. Adding all the complexity to the existing HttpResponse gets a -1 from me. It's too easy to have unintended side-effects and not really in the sweet spot of Django. It also doesn't seem to be a 1.0 requirement. Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
