Cookie system does not support "port"

[aagaande@…]

When loading my web page with a .NET application's cookie system (in WebRequest) it'll send this cookie:
sessionid=a2be2e7debe71af8d88d350c4d14d768;$Path=/;$Domain=192.168.0.2;$Port="8000"

Python will here fail on a cookie error:

  File "/home/neuron/Documents/Programming/django/django_src/django/core/handlers/wsgi.py", line 128, in _get_cookies
    self._cookies = http.parse_cookie(self.environ.get('HTTP_COOKIE', ''))
  File "/home/neuron/Documents/Programming/django/django_src/django/http/__init__.py", line 151, in parse_cookie
    c.load(cookie)
  File "/usr/lib64/python2.4/Cookie.py", line 621, in load
    self.__ParseString(rawdata)
  File "/usr/lib64/python2.4/Cookie.py", line 646, in __ParseString
    M[ K[1:] ] = V
  File "/usr/lib64/python2.4/Cookie.py", line 437, in __setitem__
    raise CookieError("Invalid Attribute %s" % K)
CookieError: Invalid Attribute port

[Malcolm Tredinnick]

Urgh! Fixing this will require rewrite django.http.parse_cookie() to use the standard library's cookielib module directly, rather than Cookie. The problem is that Cookie is only RFC2109-compliant, whereas you cookie example above requires RFC2965 understanding ($Port was only introduced as a permitted name in the latter).

It would be good if you could file a bug at ​Python's bugtracker, too, giving your example cookie and the place it causes a problem inside the Cookie mdule (they won't care about all the Django stuff). The Cookie module needs updating (I just checked: it still only supports RFC2109 in Python 2.5)

If you wanted to have a stab at fixing this yourself, the first paragraph is the approach I would take: look at the cookie handling in django/http/__init__.py and port it to use cookielib, rather than Cookie.

[aagaande@…]

​http://sourceforge.net/tracker/index.php?func=detail&aid=1564508&group_id=5470&atid=105470

Reported here, I'll see how much work it is to make a patch.

[aagaande@…]

Looked into this some more, it's not gonna be easy to implement in a clean way.

The cookielib module is tightly tied with urllib2, and extra_cookies requires two arguments.
response object - (result of urllib2.urlopen()), needs info() method, which returns an object with getallmatchingheaders() (usually mimetools.Message)
request object - (urllib2.Request), must support get_full_url(), get_host(), unverifiable() and get_origin_req_host().

From what I can tell, it'd involve changing changing modpython.py and wsgi.py's arguments to parse_cookies to passing self._get_request. But I'm not quite sure where to get the response object.

on the response object it calls:

headers = response.info()
rfc2965_hdrs = headers.getheaders("Set-Cookie2")
ns_hdrs = headers.getheaders("Set-Cookie")

​http://trac.turbogears.org/turbogears/wiki/ConvertCookies uses a fake request to convert from one to the other, but I think it'd be better to fix the system than to improve it in a hackish way. But that demonstrates use of "_cookie_from_cookie_tuple" (undocumented but used internaly by cookielib), it looks considerably easier to use that than to use a proper response object, but I dont know django's position on using undocumented api?.

[Malcolm Tredinnick]

Oh, Lord. Nice investigation, but the result is pretty sucky. I hadn't realised the two implementations were that disparate.

Python 2.3 and 2.4 will never be "fixed" in the sense of changing the Cookie module, so we still need a workaround. Need to think about the TurboGears-like approach. It's not completely insane (and it might help our testing framework as a side-effect).

[aagaande@…]

Switching to cookielib shouldn't be that complicated if you use the _cookie_from_cookie_tuple function, as you already have a request object both places parse_cookies is called, it should be relativly clean fix. If you don't use the internal api you'll need a response object as well though, and that's where things get a bit complicated, as you'll need to deal with a fake one most likely.

[Adrian Holovaty]

Fixed formatting in description.

[Simon G. <dev@…>]

Marking as wontfix given the following comment on ​Python's bugtracker

Why do you want RFC 2965 compatibility?

I'm not trolling; RFC 2965 is dead as an internet protocol (except as a
basis for implementing the older cookie protocols, as RFC 2965 +
compatibility hacks -- but $Port is not relevant in that case).  The
authors of the RFC gave up on an effort to publish errata to the RFC, due
to the complexities and the lack of interest from the internet at large.

AFAIK, $Port is not implemented by browsers (except for maybe Opera and
lynx, IIRC).  It just never caught on.

See also http://python.org/sf/1638033

[anonymous]

​seduction Here's my post on how to get laid in the next month or two. This post does not maximize your chances of "getting really good at pickup" - in fact, it does the opposite.