You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RFC 2965 BaseCookie does not support "$Port" #44019
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2006-09-24.13:05:52.000>labels= ['type-feature', 'library']
title='RFC 2965 BaseCookie does not support "$Port"'updated_at=<Date2019-04-25.05:27:37.754>user='https://bugs.python.org/aagaande'
Sending a cookie containing $Port to python's Cookie.py
causes this exception:
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
For RFC2965 compatibility more keys has to be added to
the Morsel class in the same file.
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.
Actually, I was just bit by this. In fact, RFC 2965 prohibits clients
from sending $Port if the port attribute was not included in the
Set-Cookie header. But, it turns out that the mono System.Net library
(at least) will add the attribute any time the URI includes a
non-default port number. See http://go-mono.com/forums/#nabble-f1367 I
think this is technically their bug, but it might be nice to have
something like a non-strict mode in Cookie.py that would ignore
unexpected attributes for handling cases like this.
The problem is that Cookie.py assumes names beginning with a dollar sign ($) are reserved attributes of a previous cookie-pair, rather than arbitrary cookie names. It is obvious that this was intended to support RFC 2965, although it is not documented. The module has a hard-coded list of reserved attribute names, and Port is not one of them.
IMO it would be better to treat (unknown) reserved attributes such as $Port as ordinary cookie names, and start a new “morsel”. Ignoring them would also be a better option than rejecting the whole cookie field. The dollar sign is valid for a cookie name (token) according to RFC 2109, RFC 6265, and the Netscape specification.
Activity
aagaande commentedon Sep 24, 2006
Sending a cookie containing $Port to python's Cookie.py
causes this exception:
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
For RFC2965 compatibility more keys has to be added to
the Morsel class in the same file.
jjlee commentedon Mar 14, 2007
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
devdanzin commentedon Feb 13, 2009
Does anybody else need this one or should it be closed?
[-]BaseCookie does not support "$Port"[/-][+]RFC 2965 BaseCookie does not support "$Port"[/+][-]BaseCookie does not support "$Port"[/-][+]RFC 2965 BaseCookie does not support "$Port"[/+]benanhalt commentedon May 28, 2009
Actually, I was just bit by this. In fact, RFC 2965 prohibits clients
from sending $Port if the port attribute was not included in the
Set-Cookie header. But, it turns out that the mono System.Net library
(at least) will add the attribute any time the URI includes a
non-default port number. See http://go-mono.com/forums/#nabble-f1367 I
think this is technically their bug, but it might be nice to have
something like a non-strict mode in Cookie.py that would ignore
unexpected attributes for handling cases like this.
benanhalt commentedon May 28, 2009
Grrr, the link in my last comment should have been
http://www.nabble.com/System.Net.CookieContainer-adding-inappropriate-%24Port-attribute-to-cookies--td23752882ef1367.html
Yuck.
BreamoreBoy commentedon Aug 24, 2010
This won't go anywhere unless someone provides a patch.
vadmium commentedon Apr 25, 2019
The original report comes from <https://code.djangoproject.com/ticket/2806\>. Anders was trying to parse a HTTP request Cookie field, something like:
The problem is that Cookie.py assumes names beginning with a dollar sign ($) are reserved attributes of a previous cookie-pair, rather than arbitrary cookie names. It is obvious that this was intended to support RFC 2965, although it is not documented. The module has a hard-coded list of reserved attribute names, and Port is not one of them.
IMO it would be better to treat (unknown) reserved attributes such as $Port as ordinary cookie names, and start a new “morsel”. Ignoring them would also be a better option than rejecting the whole cookie field. The dollar sign is valid for a cookie name (token) according to RFC 2109, RFC 6265, and the Netscape specification.