On Tue, 2008-07-01 at 14:02 +0400, Ivan Sagalaev wrote: > Malcolm Tredinnick wrote: > > 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. > > Malcolm, sorry, that won't work. I've implemented iterable HttpResponse > in the first place out of purely practical reason: web server times out > if a particularly long file was passed into an HttpResponse. And also it > was really slow and was consuming all the memory.
Any middleware that examines the content has to pull the content into memory in case it's an iterator. If they don't they're buggy because they're consuming the content ahead of the web server. If somebody has particular requirements like yours, then, absolutely, they should use a subclass of HttpResponse that doesn't do that. And they know the restrictions from that decision. But the default behaviour shouldn't require repetitive practices from normal, everyday middleware. > In fact this ticket appeared out of our conversation with Tai Lee. I > don't think you argument on adding complexity makes sense because not > all middleware should care about this. Why, say, TransactionMiddleware > should be affected? Or some 3rd-party HTMLValidationMiddleware which > won't touch huge iterators because it checks only HTML? This patch just > establishes a good practice to follow: if you expect a "reasonably > short" response in your middleware -- check for it. If I write a third-party middleware that behaves exactly as the content-length middleware does now, it won't work with something that can only be used as a generator. Since I won't know ahead of time what responses will be give to this middleware I am therefore forced to assume such a generator will be passed in. Thus, a change like this is saying that from now on, for all time, no middleware can look at the content of the response unless it fits into the very narrow profile in that ticket (matching one or other content types, etc). 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 -~----------~----~----~----~------~----~------~--~---
