This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gstein
Date 2002-03-18.07:05:45
SpamBayes Score
Marked as misclassified
Logged In: YES 

Andrew is correct. The buffering was turned off
(specifically) so that the reading of one response will not
consume a portion of the next response.

Jeremy first found the over-reading problem a couple years
ago, and we solved the problem then. To read the thread:

After the HTTP response's headers have been read, then it
can be determined whether the connection will be closed at
the end of the response, or whether it will stay open for
more requests to be performed. If it is going to be closed,
then it is possible to use buffering. Of course, that is
*after* the headers, so you'd actually need to do a second
dup/makefile and turn on buffering. This also means that you
wouldn't get the buffering benefits while reading headers.

It could be possible to redesign the connection/response
classes to keep a buffer in the connection object, but that
is quite a bit more involved. It also complicates the
passing of the socket to the response object in some cases.

I'm going to close this as "invalid" since the proposed fix
would break the code.
Date User Action Args
2007-08-23 13:58:53adminlinkissue508157 messages
2007-08-23 13:58:53admincreate