Created on 2013-02-20 06:48 by B. Kyven, last changed 2013-03-10 14:59 by B. Kyven.
|msg182476 - (view)||Author: B. Kyven (B. Kyven)||Date: 2013-02-20 06:48|
Hello, 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 ----------------- #LWP-Cookies-2.0 Set-Cookie3: name=value; path="/ddd/"; domain=".domain.com"; path_spec; domain_dot; secure; expires="2030-05-09 14:25:11Z"; version=0 Set-Cookie3: name=value; path="/ddd/"; domain="www.domain.com"; 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: .domain.com True True www.domain.com **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 (email@example.com) *||Date: 2013-02-26 17:35|
Hi, This is still present in the current mercurial. I'm attaching a patch that fixes the issue. Thanks.
|msg183099 - (view)||Author: Demian Brecht (dbrecht) *||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 @ http://cpansearch.perl.org/src/GAAS/libwww-perl-5.836/lib/HTTP/Cookies.pm) # 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: # # a.b.c.net Any cookie # .b.c.net Any cookie # b.c.net Netscape cookie only # .c.net Any cookie So, www.domain.com is not a valid LWP domain and therefore, unless I'm missing something, the module is functioning as expected.
|msg183117 - (view)||Author: Demian Brecht (dbrecht) *||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 (firstname.lastname@example.org) *||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 a.b.c.net, so that matchs with .b.c.net but not with b.c.net.
|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 (dbrecht) *||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. https://github.com/jjlee/mechanize 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|
|2013-03-10 14:59:50||B. Kyven||set||messages: + msg183880|
|2013-03-09 00:03:24||dbrecht||set||messages: + msg183775|
|2013-03-07 17:00:23||B. Kyven||set||messages: + msg183686|
|2013-02-27 08:27:email@example.com||set||messages: + msg183123|
|2013-02-27 07:01:15||dbrecht||set||messages: + msg183117|
|2013-02-26 23:51:firstname.lastname@example.org||set||files: - issue_17251.diff|
messages: + msg183099
versions: + Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
nosy: + email@example.com
messages: + msg183068
keywords: + patch
|2013-02-20 06:48:33||B. Kyven||create|