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.