J
Joshua Kugler
Some investigation today revealed that Cookie.py thinks these are valid
characters for names and values of cookies:
_LegalCharsPatt = r"[\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{\=]"
The rest, presumably being encoded via %NN.
I notice that (), {}, and others made the list, but not [].
Is there a reason for that? I didn't find a list of valid characters
anywhere in the cookie RFC (disclaimer: I didn't read the HTTP 1.1 RFC).
The reason this got brought up:
I'm parsing some cookies that have been set by a PHP app (out of my control,
no flames please) and it has cookies of the form name[0], name [1], and so
on which get transformed to arrays on the server side such that:
$_COOKIES['name']
Will be a list with values from name[0], name[1].
Well, when these are parsed by Cookie.py, they simply vanish because it
doesn't like the [ and ] in the cookie names. But these are set
successfully and the browser side, and are sent back to the server
successfully.
Since this is a CherryPy app, it's not as easy as just subclassing the
cookie class I want. I suppose I could sub class and then monkey patch
CherryPy, but that feels nasty. Hmm...local copy of Cookie.py that comes
before /usr/lib/python2.5 in the site path would work too.
Thoughts? Is this a bug in Cookie.py, or is PHP out of spec to send cookies
with [ and ] in the name?
j
characters for names and values of cookies:
_LegalCharsPatt = r"[\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{\=]"
The rest, presumably being encoded via %NN.
I notice that (), {}, and others made the list, but not [].
Is there a reason for that? I didn't find a list of valid characters
anywhere in the cookie RFC (disclaimer: I didn't read the HTTP 1.1 RFC).
The reason this got brought up:
I'm parsing some cookies that have been set by a PHP app (out of my control,
no flames please) and it has cookies of the form name[0], name [1], and so
on which get transformed to arrays on the server side such that:
$_COOKIES['name']
Will be a list with values from name[0], name[1].
Well, when these are parsed by Cookie.py, they simply vanish because it
doesn't like the [ and ] in the cookie names. But these are set
successfully and the browser side, and are sent back to the server
successfully.
Since this is a CherryPy app, it's not as easy as just subclassing the
cookie class I want. I suppose I could sub class and then monkey patch
CherryPy, but that feels nasty. Hmm...local copy of Cookie.py that comes
before /usr/lib/python2.5 in the site path would work too.
Thoughts? Is this a bug in Cookie.py, or is PHP out of spec to send cookies
with [ and ] in the name?
j