> Last night I actually did test it :-). You're right the difference in
> performance is less than a statistical deviation between different
> uploads over network.
Nice work. And point well made Graham!
> Creating a single wrapper object is a negligible hit but the code bloat
from making
> it
Graham Dumpleton:
Silly question. Where is the proof that using a limited stream is a
performance issue?
Last night I actually did test it :-). You're right the difference in
performance is less than a statistical deviation between different
uploads over network.
Tom Christie:
Even so, presum
Okay, since there's clearly an underlying issue here I've created a seperate
ticket for this and marked the other two tickets as duplicates of it.
So...
#15785 - HttpRequest.read(NUM_BYTES) can read beyond the end of wsgi.input
stream. (Violation of WSGI spec & under-defined behaviour) [1]
Th
> Where is the proof that using a limited stream is a performance issue? These
sorts of things are never going to be the bottleneck and sounds a bit like
premature optimisation to think that wrapping it with a length limiting
stream is going to be an issue.
There isn't any, so good point. :)
E
Silly question. Where is the proof that using a limited stream is a
performance issue? These sorts of things are never going to be the
bottleneck and sounds a bit like premature optimisation to think that
wrapping it with a length limiting stream is going to be an issue.
Graham
On Thursday, Ap
It occurs to me that (1) isn't a hit for accessing multipart POST requests,
since we're wrapping the underlying stream in LimitedStream, but beng able
to drop MultiPartParser's use of LimitBytes.
--
You received this message because you are subscribed to the Google Groups
"Django developers" g
Actually it occurs to me that (1) shouldn't be a performance hit for
accessing .POST either, because whilst you're now creating a LimitedStream,
you're able to drop MultiPartParser's use of LimitBytes.
--
You received this message because you are subscribed to the Google Groups
"Django develop
> So, OP should not be trying to read more than CONTENT_LENGTH.
>From the underlying stream, sure. The question is if it's okay to do on the
HttpRequest object. It's an issue because now that HttpRequest exposes a
file-like interface to the stream some users are likely to do things like
this:
On Thursday, April 7, 2011 1:00:32 PM UTC+10, Ivan Sagalaev wrote:
>
> On 04/03/2011 07:03 AM, Tom Christie wrote:
> > It's not very obvious from the docs or source if HttpRequest.read() can
> > always be safely treated as a limited input stream, or if the developer
> > needs to respect HttpReque
On 04/03/2011 07:03 AM, Tom Christie wrote:
It's not very obvious from the docs or source if HttpRequest.read() can
always be safely treated as a limited input stream, or if the developer
needs to respect HttpRequest.META['CONTENT_LENGTH'].
As far as I can tell the intention is that it can alway
I've created two tickets for this, with patches and tests...
http://code.djangoproject.com/ticket/15762 - WSGIRequest should wrap the
test client wsgi.input in LimitedStream
http://code.djangoproject.com/ticket/15763 - MultiPartParser's LimitBytes is
now redundant.
It's possible that I've misun
11 matches
Mail list logo
