On Jul 1, 1:02 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> 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
On Sep 23, 3:54 am, mrts <[EMAIL PROTECTED]> wrote:
> +1 for adding a way to say "process_response should never be called on
> this response".
>
> Taking a quick look at the source, HttpResponse seems to support
> iteration already:
>
> def __iter__(self):
> self._iterator =
On Jul 4, 2:26 am, Tai Lee <[EMAIL PROTECTED]> wrote:
> > 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
> 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.
Would this disable ALL middleware from running? Or
On Jul 1, 7:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> 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
Certainly the implementation of the patch is not ideal (by accessing
private attributes on HttpResponse), which is why I brought it up for
discussion before going any further.
I do feel that there is a real benefit and even requirement in some
cases to supporting streaming HttpResponse objects.
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
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.
>
>
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
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
> >
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
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
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
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
14 matches
Mail list logo
