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 gregory.p.smith
Recipients ajaksu2, cjw296, facundobatista, ggenellina, gregory.p.smith, pitrou, reacocard, schmir
Date 2009-08-15.06:27:43
SpamBayes Score 3.4986508e-07
Marked as misclassified No
Message-id <1250317666.65.0.92920584405.issue2576@psf.upfronthosting.co.za>
In-reply-to
Content
Okay, I do not think this has been fixed yet.  Anyone calling
getresponse() can indeed use buffering=True, it can mess things up if
the do not close the connection afterwards.

The addition of the sockbuf parameter to HTTPConnection as proposed in
buffered_socket.diff will work, but I'd follow the earlier work's lead.
 Don't expose it as the "sockbuf" integer.  Just use a boolean
"buffering" parameter that defaults to False.  When true, do the same
thing you do with sockbuf != 0.

I see little value in actually being able to specify the exact buffer
size used on the internal makefile on the HTTPConnection.  The default
will be sufficient.

If you still want the user to be able to control it, perhaps add a
HTTPConnection class attribute that defaults to -1
(socket.socket.makefile()'s bufsize default value) that you pass to
makefile.  Users can subclass HTTPConnection and give it a new value in
that case.  Personally I'd call that overkill.
History
Date User Action Args
2009-08-15 06:27:46gregory.p.smithsetrecipients: + gregory.p.smith, facundobatista, ggenellina, pitrou, ajaksu2, schmir, cjw296, reacocard
2009-08-15 06:27:46gregory.p.smithsetmessageid: <1250317666.65.0.92920584405.issue2576@psf.upfronthosting.co.za>
2009-08-15 06:27:45gregory.p.smithlinkissue2576 messages
2009-08-15 06:27:43gregory.p.smithcreate