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 martin.panter
Recipients amaury.forgeotdarc, ipatrol, loewis, martin.panter, orsenthil, pitrou, trent, vklogin
Date 2015-01-24.12:59:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1422104370.84.0.232188004475.issue9740@psf.upfronthosting.co.za>
In-reply-to
Content
See Issue 3566 about tweaking the “http.client” module’s BadStatusLine handling to be more helpful when implementing persistent connections. I am dumping some thoughts here about persistent connections with the “http.client” module, gained by working on that bug.

* Lib/xmlrpc/client.py appears to have persistent connection support, so may be useful for this bug.

* RFC 7230 §6.5 <https://tools.ietf.org/html/rfc7230#section-6.5> mentions monitoring for connection closure. This could be be partly implemented inside HTTPConnection by polling for closure before sending a request, but to fully implement might require the co-operation of the user calling into the module to check for closure at other times using select() or similar.

* Current “http.client” assumes that each socket.makefile() object will not buffer any data from a subsequent response. Unsure if this is a problem in the real world, but I ran into it implementing test cases. E.g. if the server anticipates the first few bytes of the subsequent response:

c.send(b"HTTP/1.1 200 Okay\r\nContent-Length: 0\r\n\r\n" b"HTTP/")

then the client misses the “HTTP/” and raises BadStatusLine("1.1 200 Okay\r\n").
History
Date User Action Args
2015-01-24 12:59:30martin.pantersetrecipients: + martin.panter, loewis, amaury.forgeotdarc, orsenthil, pitrou, trent, ipatrol, vklogin
2015-01-24 12:59:30martin.pantersetmessageid: <1422104370.84.0.232188004475.issue9740@psf.upfronthosting.co.za>
2015-01-24 12:59:30martin.panterlinkissue9740 messages
2015-01-24 12:59:30martin.pantercreate