Sounds like a ticket is called for.
To aid the debugging process, if you can provide a complete standalone
example (or at least a complete set of duplication instructions), that
would be most helpful.
Yours,
Russ Magee %-)
Mark, can you also CC: me ('isagalaev') on this ticket. I have an idea
where it can be broken.
I remember that the initial patch was always passing a `size` parameter
into .read() of the underlying stream. Russell can you remember why you
changed it to pass or not pass the `size` according to how it was passed
into the outer .read()?
The only changes I'm aware of making were related to getting
readline() to behave correctly. The patch as submitted didn't return
the right values for the readline(len) case. Which call to read() are
you saying is wrong?
Yours,
Russ Magee %-)
Sorry, my memory has failed me here. Indeed I was thinking about your
fixes in readline and they shouldn't have anything to do with the bug.
From a quick look it can be fixed in two ways:
- HttpRequest.raw_post_data can always explicitly ask for content_length
bytes. If content_length is absent just treat it as 0.
- WSGIRequest can wrap all wsgi.input into a LimitedStream (now it's
done only for known fragile sockets).
I don't like pure Python wrappers moving bytes in performance critical
places, so I'd go with the first approach. Does anyone foresee any bad
things with it?
The former looks like the right approach to me -- in fact, it looks to
be a pretty close rendition of what the code used to do. I've made the
change in r14435.
Yours,
Russ Magee %-)