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
13 matches
Mail list logo
