[ python-Bugs-1372650 ] Cookie and multiple names

[SourceForge.net]

Bugs item #1372650, was opened at 2005-12-03 18:47
Message generated for change (Comment added) made by valankar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Viraj Alankar (valankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cookie and multiple names

Initial Comment:
The cookie specification described here:

http://wp.netscape.com/newsref/std/cookie_spec.html

states that multiple names of cookies can be sent. This does not seem 
to parse correctly with the Cookie module due to its dictionary storage.  
When parsing cookies via modpython, only the last cookie is used. I 
think it would be better to only use the first value, since that is what 
the specification says. Or provide for a way to store multiple names 
with different paths.


----------------------------------------------------------------------

>Comment By: Viraj Alankar (valankar)
Date: 2005-12-04 13:46

Message:
Logged In: YES 
user_id=107970

Heh I guess that means I should try to write a patch. Might be a good learning 
experience for me.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2005-12-04 09:16

Message:
Logged In: YES 
user_id=261020

OK, I see.

I agree that it's a bug, but I'm undecided whether the
existing behaviour should be fixed.  It's true that clients
are supposed to (and do) send the most specific cookie last,
so this bug could cause servers to see the cookie from, eg
path '/cgi-bin' instead of from path '/mystuff/cgi-bin'. 
However, module Cookie is old and stable, and a patch might
break servers expecting the current behaviour.  I *suppose*
such breakage is fairly unlikely, so I wouldn't object to a
patch.

I certainly don't see anybody objecting to a patch to add a
new method to allow access to multiple cookies of the same
name  without altering the existing dict interface (repr()
could change, but not eg. .get()).

Either way, I suspect a patch is only likely to appear from
somebody who is actually using such cookies, though :-)


----------------------------------------------------------------------

Comment By: Viraj Alankar (valankar)
Date: 2005-12-04 07:07

Message:
Logged In: YES 
user_id=107970

Basically, sometimes a web client will send 2 instances of the same name:

Cookie: mycookie=foo; mycookie=bar

The specs say that the first one is the one that should be used. The other 
cookies listed are the inherited ones from paths that a prefix of the current 
URL. When this is parsed by the Cookie module, mycookie gets set to bar 
when it should be foo.

Another example might be:

Cookie: mycookie=foo; path=bar
Cookie: mycookie=foo; path=baz

In this case there should be 2 cookies with the name 'mycookie'. The 
uniqueness is determined by the different paths.

Thanks.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2005-12-04 06:52

Message:
Logged In: YES 
user_id=261020

I don't get it:

>>> import Cookie
>>> c = Cookie.SimpleCookie()
>>> c.load("foo=bar; bar=baz")
>>> c
<SimpleCookie: bar='baz' foo='bar'>


Where's the problem?

In general, don't pay too much attention to that standard, BTW:

http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470