urllib still doesn't support persistent connections

[C19]

BPO	16942
Nosy	@terryjreedy, @orsenthil, @bitdancer, @demianbrecht
Superseder	bpo-16901: In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work
Files	cookiejar_16942.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-04-20.17:48:44.864>
created_at = <Date 2013-01-12.08:12:56.642>
labels = ['type-bug', 'library', 'docs']
title = "urllib still doesn't support persistent connections"
updated_at = <Date 2013-04-20.17:48:44.858>
user = 'https://bugs.python.org/C19'

bugs.python.org fields:

activity = <Date 2013-04-20.17:48:44.858>
actor = 'orsenthil'
assignee = 'docs@python'
closed = True
closed_date = <Date 2013-04-20.17:48:44.864>
closer = 'orsenthil'
components = ['Documentation', 'Library (Lib)']
creation = <Date 2013-01-12.08:12:56.642>
creator = 'C19'
dependencies = []
files = ['29215']
hgrepos = []
issue_num = 16942
keywords = ['patch']
message_count = 9.0
messages = ['179777', '179778', '179780', '179793', '182845', '183020', '183103', '186270', '187444']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'orsenthil', 'r.david.murray', 'docs@python', 'C19', 'demian.brecht']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '16901'
type = 'behavior'
url = 'https://bugs.python.org/issue16942'
versions = ['Python 2.6', 'Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']

[C19]

Is it means that we should use MozillaCookieJar LWPCookieJar or MSIECookieJar?

But the document says "perhaps save cookies to, a file on disk. "
http://docs.python.org/2/library/cookielib.html?highlight=filecookiejar#cookielib.FileCookieJar

it looks like FileCookieJar is just a base class.it shouldn't be used on normal purpose(like save your cookie).then the document should be modified.
but I think it's better to make the FileCookieJar works as expected.

[C19]

# TODO(jhylton): Should this be redesigned to handle
# persistent connections?

    # We want to make an HTTP/1.1 request, but the addinfourl
    # class isn't prepared to deal with a persistent connection.
    # It will try to read all remaining data from the socket,
    # which will block while the server waits for the next request.
    # So make sure the connection gets closed after the (only)
    # request.
    headers["Connection"] = "close"

http://bugs.python.org/issue9740
this has been a long time..how many is annoyed by this..Count me in..
persistent connections may not be easy on various OS and act the same.
I'm just satisfied if it works on linux.

[C19]

https://github.com/shazow/urllib3
do we really have to use a 3rd party module for this ?..

[bitdancer]

Please open a separate issue for your enhancement request in your second message (assuming there isn't already one open). I'm not sure what your third message is about, but it also sounds off topic for your original bug report.

For the FileCookieJar issue, I agree that the documentation is unclear. However, it is perfectly reasonable to have a documented base class that is an Abstract Base Class, and there is no reason for us to invent our own unique cookie file format just to make FileCookieJar work by itself. ABCs didn't exist when FileCookieJar was implemented, so it should be turned in to one for 3.4 (it might break working code, so we shouldn't do that for bug fix releases). That way you would get a useful error when you try to instantiate it, rather than when you try to use it. And the docs should document it as being a base-class-only for all active releases.

[demianbrecht]

I've changed FileCookieJar to use the ABCMeta metaclass and updated the concrete implementations. If this patch looks sufficient, I'll make an update to the docs as well.

[terryjreedy]

+class FileCookieJar(CookieJar, metaclass=ABCMeta):
+ """Abstract Base Class for any file-based CookieJar."""

Is it just me or is it a bit strange to derive an abstract base class from a concrete class? Is CookieJar meant to be directly used?

+ with open(self.filename) as f:
+ magic = f.readline()
+ if not self.magic_re.search(magic):
+ f.close()
+ raise LoadError(
+ "%r does not look like a Netscape format cookies

f.close() seems not needed as doing that in __exit__ as a major point of with open... statements.

[demianbrecht]

http://bugs.python.org/issue1690 seems to be a duplicate of this one (at least the initial report). 16901 (imho) is documented more clearly than this one, so can this one be closed as duplicate?