Title: LWPCookieJar load() set domain_specifed wrong
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 2.7, Python 2.6
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: B. Kyven,
Priority: normal Keywords: patch

Created on 2013-02-20 06:48 by B. Kyven, last changed 2019-01-24 23:54 by demian.brecht.

Messages (8)
msg182476 - (view) Author: B. Kyven (B. Kyven) Date: 2013-02-20 06:48

I am using LWPCookieJar to store cookies. But I am having trouble.
Saving is fine, load is wrong. I use Cookie.domain_specified to judge if domain exist.

save the following to test.lwp
Set-Cookie3: name=value; path="/ddd/"; domain=""; path_spec; domain_dot; secure; expires="2030-05-09 14:25:11Z"; version=0
Set-Cookie3: name=value; path="/ddd/"; domain=""; path_spec; secure; expires="2030-05-09 14:25:11Z"; version=0

>cj = LWPCookieJar('test.lwp').load()
>for c in cj:
>    print c.domain, c.domain_specified, c.domain_initial_dot

output:       True      True  **False**   True

If understood correctly, domain_specified should equal bool(c.domain ="").

This is seen on 2.7 and 2.6.
msg183068 - (view) Author: Maximiliano Curia ( * Date: 2013-02-26 17:35

This is still present in the current mercurial.

I'm attaching a patch that fixes the issue.

msg183099 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2013-02-26 23:49
According to some digging around that I've done, this issue may be invalid:

(I couldn't find an RFC or detailed spec of the LWP format, so reading from libwww-perl source @

# Try with a more general domain, alternately stripping
# leading name components and leading dots.  When this
# results in a domain with no leading dot, it is for
# Netscape cookie compatibility only:
#	Any cookie
#	Any cookie
#	Netscape cookie only
#	Any cookie

So, is not a valid LWP domain and therefore, unless I'm missing something, the module is functioning as expected.
msg183117 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2013-02-27 07:01
That was silly of me. What I /meant/ to say was that, for this specific report, it's functioning as expected. However, the logic in LWPCookieJar isn't entirely correct. As noted in the comments from libwww-perl, the reported URL is in fact, an invalid LWP cookie. What's missing is the logic to deal with other, valid cookies. 

domain_specified = domain.starts_with('.') is incorrect as a four part domain name (a.b.c.d) /is/ a valid LWP domain.

This should likely be patched.

Another question that I have though, is why is LWPCookieJar even part of the stdlib? It's relatively well documented that it is not known to be compatible with any browser. I'm curious as to how heavily used it is and what the rational was to include it (dev might be a better place to ask this, I'm not sure).
msg183123 - (view) Author: Maximiliano Curia ( * Date: 2013-02-27 08:27
I've deleted my previous patch, as I found the code working as intended.

The domain_specified signals whether the domain stores came from a Domain: tag inside a Set-Cookie request or is taken from the hostname of the request.

The rfc2965 dictates that a value taken from a Domain: tag should be
prepended with a "." if the values doesn't include it. Once stored in a LWPCookieJar the same logic is used to signal if the domain_specified is true or false. Thus the observed behaviour.

The LWP-Cookies-2.0 format is an extension to the perl format, that seeks compatibility adding some features.

About the domain matching, the rfc2965 documents this. I think the perl comment is an example for, so that matchs with but not with
msg183686 - (view) Author: B. Kyven (B. Kyven) Date: 2013-03-07 17:00
I now realized LWPCookieJar is a subclass of CookieJar but it behaves differently. I believe there are other quirks I haven't discovered, like expire=None which cause exception in LWPCookieJar, but works fine for CookieJar. Sadly the doc didn't mention them.

The official python document introduced 2 file cookiejar, one is Mozilla's FileCookieJar, which is explicitly advised as depricated.
LWPCookieJar which is human-readable seems the only advisable chooice to me. But it turns out not that simple.
My guess is that not many people use this module, or the expire=None problem and this dot question should be quite easy to spot on google. 

So forks, could your suggest how does other python user deal with cookie storage. Do they just pickle the cookie objects and save to file?
Or any via 3rd party cookie batteries? What's their pro/cons ? 

LWPCookie's usage is strage to me and ,I believe, many average users, I guess many people like me will be willing to know alternatives.
msg183775 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2013-03-09 00:03
@B. Kyven: What are you trying to achieve? 

LWP is intended to be used with libwww-perl libary, which is not known to be compatible with any browsers (not sure whether or not this has any bearing on what you're doing).

Really, IMHO, this entire module is in need of a whole lot of love. Unfortunately, I don't think there's much interest in it, so I'm unsure of whether or not that love will happen any time soon. looks like it has its own implementation of the MozillaCookieJar (extending on the FileCookieJar). If/how it differs from the stdlib implementation I'm not sure.
msg183880 - (view) Author: B. Kyven (B. Kyven) Date: 2013-03-10 14:59
@Demian Brecht
Um, I do realize the lack of popularity of this module, now.

What I try to achieve is simple. store persistent cookies in a way, that's told to be standard in python ?

Actually, I was trying to sync QtCookiesJar to CookieJar to make urllib2 works with cookie sessions opened in QtWebKit to skip the heavy javascript powered login process.(now it works either way not both) And I need a way to save persistent cookie. Maybe I need to rethink my strategy. Any thoughts?
Date User Action Args
2019-01-24 23:54:48demian.brechtsetnosy: - demian.brecht
2013-03-10 14:59:50B. Kyvensetmessages: + msg183880
2013-03-09 00:03:24demian.brechtsetmessages: + msg183775
2013-03-07 17:00:23B. Kyvensetmessages: + msg183686
2013-02-27 08:27:38maxy@debian.orgsetmessages: + msg183123
2013-02-27 07:01:15demian.brechtsetmessages: + msg183117
2013-02-26 23:51:23maxy@debian.orgsetfiles: - issue_17251.diff
2013-02-26 23:49:41demian.brechtsetnosy: + demian.brecht
messages: + msg183099
2013-02-26 17:35:50maxy@debian.orgsetfiles: + issue_17251.diff
versions: + Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
nosy: +

messages: + msg183068

keywords: + patch
2013-02-20 06:48:33B. Kyvencreate