On Tue, 2008-07-01 at 14:42 +0400, Ivan Sagalaev wrote: > Malcolm Tredinnick wrote: > > 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. > > Agreed. > > > But the default behaviour shouldn't > > require repetitive practices from normal, everyday middleware. > > What exactly you mean by "repetitive practices"? I'm afraid my English > fails me again, sorry!
At the moment, lots of pieces of middleware are buggy because they consume the content from response.content and neither the content property nor the middleware itself puts the content back into the response. Those pieces of middleware should, with the current state of the code, be checking if the response was created from an iterator and, if so, be careful to replace the content after use by poking into the internals of the response. Every single piece of middleware that examines response.content needs to do this (this is the bit that requires the repetition). Of course, that's a silly requirement (and requires poking at non-public pieces of the response). The response should just return a copy of the content when response.content is accessed, which means turning any iterator into a proper string. > > 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). > > If a middleware has to look at the content - it will. But why not make > certain standard middleware not required to look at the content? They > will be more useful then, and it doesn't imply, IMHO, that everyone > should do it. No? 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. Since generators would be permitted in that world, I have to treat them as possible in my middleware code. So I cannot examine the content. Otherwise my middleware is crippled as a reusable piece of code: it would have to carry a big warning saying "cannot be used unless you know your responses will never use generators", which means I have to investigate the details of every third-party app I have installed before I can safely use my middleware. That simply is not going to be good practice. I really don't see that it's worth the enormous complexity it brings at the moment to introduce this. It's not something that cannot wait and be trialled in various approaches after 1.0, but rushing to create some public interface and functionality promises right now so that generators become fully supported in HttpResponse is going to lead to bugs. The ticket itself already proposes some things that will lead to bugs: for example, content-length must *always* be set, since chunked transfer-encoding isn't permitted with WSGI, so it's not a question of checking _is_string or not -- which, btw, is an internal attribute that middleware should never access -- but, rather, a question of whether the header has already been set. 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 -~----------~----~----~----~------~----~------~--~---
