>> - A hypothetical middleware that appends debug information to the end
>> of the response. debug-toolbar may be able to work like this.
> Looking for the boils down to the same problem as above, and can't be
> implemented without consuming the content for the same reason.
It can be done, it'
Hi Gavin,
The whole point of the HttpStreamingResponse API to access the content is to be
incompatible with HttpResponse. Otherwise it's too easy to consume streamed
content accidentally.
Re-introducing a common API ("streaming_content") would remove that benefit, it
would be confusing in the
- GzipMiddleware (compress_string(x) == compress_sequence([x]))
- StripWhitespaceMiddleware
- ContentDoctorMiddleware (https://github.com/unomena/django-content-doctor)
- A hypothetical middleware that appends debug information to the end
of the response. debug-toolbar may be able to work like
2012/11/28 Gavin Wahl
> I would like to avoid having two code paths, one with streaming and one
> without, in new middleware.
>
Hi Gavin,
Could you give an example of a middleware that:
- needs to alter the content,
- will work identically both on regular HttpResponses and
StreamingHttpResp
I would like to avoid having two code paths, one with streaming and one
without, in new middleware.
If `HttpResponse` followed the the `streaming_content` API as well, when
writing a streaming-aware middleware instead of writing
if response.streaming:
response.streaming_content =
wr
Le 22 oct. 2012 à 23:50, Aymeric Augustin
a écrit :
> There's encoding information available both in self._charset and in the
> Content-Encoding header.
I was confused — Content-Encoding is typically "gzip" of "deflate"; it has
nothing to do with the response charset.
For all practical val
On 23 loka, 00:51, Aymeric Augustin
wrote:
> Hello,
>
> While I'm working on HttpResponse, I'd like to resolve two related tickets.
> Here's my plan for discussion.
>
> #6527 is about normalizing how HttpResponse deals with iterators. For more
> background, see part 1 of the first email of this
Hello,
While I'm working on HttpResponse, I'd like to resolve two related tickets.
Here's my plan for discussion.
#6527 is about normalizing how HttpResponse deals with iterators. For more
background, see part 1 of the first email of this thread.
Let's take an HttpResponse instantiated with a
Hello,
I just added StreamingHttpResponse and closed #7581. There've been many
contributions to this ticket over the years; I committed the simplest thing
that could possibly work. If I missed something important, please let me know.
The yak shaving goes on with:
- https://code.djangoproject.co
Hello,
I've just written a (final?) proposal on the ticket:
https://code.djangoproject.com/ticket/7581#comment:36
If you still want to weigh on this issue or issue a veto (there were several -1
over the last 4 years), now is the time.
Otherwise I'll update the patch and try to commit it in 1.5.
On 29 syys, 07:45, Tai Lee wrote:
> Docs have been added (patch should be complete now) and pull request has
> been opened, at Anssi's request.
>
> https://groups.google.com/d/topic/django-developers/RrNPfuJxnlM/discu...
To me it seems the use of streaming responses in static file serving
will ca
Docs have been added (patch should be complete now) and pull request has
been opened, at Anssi's request.
https://groups.google.com/d/topic/django-developers/RrNPfuJxnlM/discussion
Cheers.
Tai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" gr
Hi Aymeric & Anssi,
Thanks for your feedback. I have updated my branch with an implementation
of a new `HttpStreamingResponse` class plus tests and updated the ticket.
Please take a look and let me know if this is moving in the right
direction, and if there is any other feedback. If the approac
On 25 elo, 23:22, Aymeric Augustin
wrote:
> In my opinion, option 2 is reasonable. I'm -0 on a stream_content keyword
> argument for HttpResponse. I +1 on adding a separate HttpStreamingResponse
> class, because it better reflects the difference in behavior, and because it
> makes it possible t
Hi Tai,
Thanks for your work and sorry for the late answer. I just had the time to
review the discussion.
In my opinion, option 2 is reasonable. I'm -0 on a stream_content keyword
argument for HttpResponse. I +1 on adding a separate HttpStreamingResponse
class, because it better reflects the
> I don't think what you are suggesting would be necessary. Stream-capable
> middleware could avoid having to handle both cases by simply wrapping
> response.content with a new iterator in all cases, if they want to.
> Non-streaming responses can still be iterated. They just have fewer
> iterat
Hi Ryan,
I don't think what you are suggesting would be necessary. Stream-capable
middleware could avoid having to handle both cases by simply wrapping
response.content with a new iterator in all cases, if they want
to. Non-streaming responses can still be iterated. They just have fewer
iterat
> In 1.7 we could raise a loud exception when stream_content=True and
> response.content is accessed directly. Middleware can do nothing if they
> don't care about or need to worry about streaming responses. If they are
> capable of functioning with a streaming response, they can check
> respon
I have updated the patch on my GitHub repository after some discussion on
IRC with Anssi. The patch applies on master again now, it consumes
generator content on access instead of on assignment, and raises a
PendingDeprecationWarning if you create an HttpResponse with
stream_content=True and th
On 23 elo, 15:51, Anssi Kääriäinen wrote:
> My current feeling about the options is that this is getting
> complex... So, as-simple-as-can-be solution:
> - Add a flag to the response which tells if the response is
> streaming or not. You can set this in response's.__init__. We might be
> able to
On 23 elo, 12:52, Tai Lee wrote:
> After discussion with akaarai and mYk on IRC, I have two updated proposals.
>
> OPTION 6:
>
> 1. Consume `HttpResponse.content` on first access, so that it can be read
> multiple times and eliminate the current buggy behaviour (e.g.
> `response.content != respons
After discussion with akaarai and mYk on IRC, I have two updated proposals.
OPTION 6:
1. Consume `HttpResponse.content` on first access, so that it can be read
multiple times and eliminate the current buggy behaviour (e.g.
`response.content != response.content`) when a generator is passed in a
It sounds like the preferred solution is still "don't do that", which I
think corresponds most closely with option 1. Simply consuming generator
content in `HttpResponse.__init__()` in all cases would prevent some of the
surprising behaviour we are seeing, but it would completely break any
supp
Hi Tai,
On Mon, Aug 20, 2012 at 08:39:07AM -0700, Tai Lee wrote:
> I'd like to re-visit the discussion surrounding #7581 [1], a ticket about
> streaming responses that is getting quite long in the tooth now, which Jacob
> finally "accepted" 11 months ago (after a long time as DDN) and said that it
On Mon, Aug 20, 2012 at 3:21 PM, Alex Gaynor wrote:
> My inclination is that we should kill .content entirely, middleware that
> wants to rewrite the response will have two choices:
>
> 1) explicitly evaluate the entire response, and return a new HttpResponse
> object
> 2) return s anew HttpRespo
On 20 elo, 22:21, Alex Gaynor wrote:
> My inclination is that we should kill .content entirely, middleware that
> wants to rewrite the response will have two choices:
>
> 1) explicitly evaluate the entire response, and return a new HttpResponse
> object
> 2) return s anew HttpResponse object that
On Mon, Aug 20, 2012 at 12:19 PM, Anssi Kääriäinen
wrote:
>
>
> On 20 elo, 18:39, Tai Lee wrote:
> > I'd like to re-visit the discussion surrounding #7581 [1], a ticket about
> > streaming responses that is getting quite long in the tooth now, which
> > Jacob finally "accepted" 11 months ago (aft
On 20 elo, 18:39, Tai Lee wrote:
> I'd like to re-visit the discussion surrounding #7581 [1], a ticket about
> streaming responses that is getting quite long in the tooth now, which
> Jacob finally "accepted" 11 months ago (after a long time as DDN) and said
> that it is clear we have to do *som
I'd like to re-visit the discussion surrounding #7581 [1], a ticket about
streaming responses that is getting quite long in the tooth now, which
Jacob finally "accepted" 11 months ago (after a long time as DDN) and said
that it is clear we have to do *something*, but *what* remains to be seen.
29 matches
Mail list logo
