Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#2806 closed defect (wontfix)

Cookie system does not support "port"

Reported by: aagaande@… Owned by: Malcolm Tredinnick
Component: Contrib apps Version: master
Severity: normal Keywords: cookies
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by Adrian Holovaty)

When loading my web page with a .NET application's cookie system (in WebRequest) it'll send this cookie:

Python will here fail on a cookie error:

  File "/home/neuron/Documents/Programming/django/django_src/django/core/handlers/", 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/", line 151, in parse_cookie
  File "/usr/lib64/python2.4/", line 621, in load
  File "/usr/lib64/python2.4/", line 646, in __ParseString
    M[ K[1:] ] = V
  File "/usr/lib64/python2.4/", line 437, in __setitem__
    raise CookieError("Invalid Attribute %s" % K)
CookieError: Invalid Attribute port

Change History (9)

comment:1 Changed 12 years ago by 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/ and port it to use cookielib, rather than Cookie.

comment:2 Changed 12 years ago by aagaande@…

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

comment:3 Changed 12 years ago by 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 and'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 =
rfc2965_hdrs = headers.getheaders("Set-Cookie2")
ns_hdrs = headers.getheaders("Set-Cookie") 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?.

comment:4 Changed 12 years ago by Malcolm Tredinnick

Owner: changed from Adrian Holovaty to 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).

comment:5 Changed 12 years ago by 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.

comment:6 Changed 12 years ago by Adrian Holovaty

Description: modified (diff)

Fixed formatting in description.

comment:7 Changed 11 years ago by Simon G. <dev@…>

Triage Stage: UnreviewedAccepted

comment:8 Changed 11 years ago by Simon G. <dev@…>

Resolution: wontfix
Status: newclosed

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

comment:9 Changed 11 years ago by 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.

Note: See TracTickets for help on using tickets.
Back to Top