Message234609
| 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"). |
|