Code

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#2806 closed defect (wontfix)

Cookie system does not support "port"

Reported by: aagaande@… Owned by: mtredinnick
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)

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

Attachments (0)

Change History (9)

comment:1 Changed 8 years ago by mtredinnick

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.

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 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 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?.

comment:4 Changed 8 years ago by mtredinnick

  • Owner changed from adrian to mtredinnick

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 8 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 7 years ago by adrian

  • Description modified (diff)

Fixed formatting in description.

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

  • Triage Stage changed from Unreviewed to Accepted

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

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:9 Changed 7 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.