Martin Panter added the comment:

Tweaking the title to exclude servers. Persistent connections have apparently 
been supported in the low-level server for ages, since Issue 430706, and now 
that the close_connection flag is documented (Issue 23410), someone 
implementing a server should be able to use that to implement HTTP 1.0 
keep-alive connections, etc as well.

For the client aspect, this bug is rather vague about exactly what should be 
added. Issue 3566 has been committed and closed, meaning now we should have an 
easier way to detect when a persistent connection has been dropped by the 
server. Here is a list of other things that come to mind:

1. Allow a way of polling for an unsolicited disconnection or 408 response 
without sending a request, either by:
  * exposing the sock attribute or adding a fileno() method, so that select() 
can be called, or
  * adding a new poll_response() or similar method
2. Poll if disconnected before sending a request, to avoid in 99% of cases the 
problem with non-idempotent requests (like POST) where you do not know if they 
were accepted or not
3. Change urlopen() to reuse the same connection when retrying a request (e.g. 
for redirects, authentication)
4. A urllib.request.PersistentConnectionHandler class or other urlopen() level 
API where the caller can reuse the same connection for multiple requests to the 
same host. Like HTTPConnection mainly does, but with the extra redirect, error, 
etc handling of urlopen().

I think the first point is important to do, because I have had to work around 
this by relying on the undocumented “HTTPConnection.sock” attribute. Once point 
1 is done, point 2 might be easy to do in user code.

The last two points I currently don’t have so much personal interest in seeing 
in the standard library, unless others also want something like them.

----------
title: Support for HTTP 1.1 persistent connections throughout the standard 
library -> Client support for HTTP 1.1 persistent connections throughout the 
standard library

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9740>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to