[issue4879] Allow buffering for HTTPResponse

Martin Panter added the comment: Opened Issue 23377 for the problem of dropping extra buffered data at the end of a response. -- nosy: +vadmium ___ Python tracker ___ ___

[issue4879] Allow buffering for HTTPResponse

Gregory P. Smith added the comment: Already reverted in r74522 | gregory.p.smith | 2009-08-18 22:33:48 -0700 (Tue, 18 Aug 2009) for that reason. -- ___ Python tracker ___ _

[issue4879] Allow buffering for HTTPResponse

Kristján Valur Jónsson added the comment: Gregory, please revert your change (74463). There is no "extra data" after the response, since such data can only be generated as a result of a new "request". Your change has disabled the HTTP/1.1 keepalive capability, causing test failurres in xmlrpc

[issue4879] Allow buffering for HTTPResponse

R. David Murray added the comment: I think I'll open a new ticket instead. -- stage: commit review -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue4879] Allow buffering for HTTPResponse

Changes by R. David Murray : -- priority: -> normal stage: -> commit review status: closed -> open ___ Python tracker ___ ___ Python-

[issue4879] Allow buffering for HTTPResponse

R. David Murray added the comment: And that update causes failures in test_xmlrpc. -- nosy: +r.david.murray ___ Python tracker ___ ___

[issue4879] Allow buffering for HTTPResponse

Gregory P. Smith added the comment: trunk r74463 now forces the HTTPResponse to close afterwards when buffering=True to avoid the issue. -- ___ Python tracker ___ ___

[issue4879] Allow buffering for HTTPResponse

Gregory P. Smith added the comment: I believe there will be a problem with the patch committed in r68532. If getresponse(buffering=True) is called, extra data on the socket may be consumed by the socket.makefile() buffer which will cause problems if the connection is not closed immediately afte

[issue4879] Allow buffering for HTTPResponse

Kristján Valur Jónsson added the comment: I'm afraid I misunderstood the problem. Yes, since u.fp is now a io.BufferedReader() rather than a socket.Socket (), the _sock member has moved. But looking at the other assertions in test_urllib2net.py, you can see the different ways the code uses to

[issue4879] Allow buffering for HTTPResponse

Kristján Valur Jónsson added the comment: The socket.socket.makefile() now returns a quite different kind of object, namely a SocketIO thing. This comes as a result of the IO refactoring in 3.0. The good side to this is that old and naughty apps have been forbidden to access the _sock member

[issue4879] Allow buffering for HTTPResponse

Amaury Forgeot d'Arc added the comment: This causes failures in test_urllib2net. The fix is easy: a handful of -self.assertTrue(u.fp._sock.gettimeout() is None) +self.assertTrue(u.fp.raw._sock.gettimeout() is None) But doesn't this show a backward-incompatible change? or is the

[issue4879] Allow buffering for HTTPResponse

Kristján Valur Jónsson added the comment: Checked in r69209 to py3k ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue4879] Allow buffering for HTTPResponse

Kristján Valur Jónsson added the comment: Adding crossref to http://bugs.python.org/issue4448 regarding the porting of this feature to 3.1 ___ Python tracker ___

[issue4879] Allow buffering for HTTPResponse

Benjamin Peterson added the comment: Kristján, could you merge this change into the Py3k branch, please? -- nosy: +benjamin.peterson ___ Python tracker ___ __

[issue4879] Allow buffering for HTTPResponse

Kristján Valur Jónsson added the comment: Checked in as revision: 68532 -- resolution: -> accepted status: open -> closed ___ Python tracker ___

[issue4879] Allow buffering for HTTPResponse

Kristján Valur Jónsson added the comment: Yes, if you think so. But my intention was to indicate that the "nobuffering" is a special feature the user can turn off to resort to what could be considered normal, buffered, behaviour. But either way is fine, and I'll be happy to change it. _

[issue4879] Allow buffering for HTTPResponse

Antoine Pitrou added the comment: Why not name the parameter buffering=False rather than nobuffer=True? Sounds more "natural" to me. -- nosy: +pitrou ___ Python tracker ___ _

[issue4879] Allow buffering for HTTPResponse

Changes by Kristján Valur Jónsson : -- title: Allo buffering for HTTPResponse -> Allow buffering for HTTPResponse ___ Python tracker ___ __