This patch implements part of bug 1372650.

Sometimes a web client will send 2 instances of the same name:

Cookie: mycookie=foo; mycookie=bar

The specs listed here:

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

state 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.

This patch changes Cookie.py to only use the first instance of duplicate
cookies when parsing cookie strings.

That link is misleading and just confuses you. :) Instead read John J. Lee's great explanation at the referenced bug report. I have tested the patch and it works as expected. Without the patch:

>>> c = SimpleCookie('foo=33;foo=34')
>>> print c
Set-Cookie: foo=34

With the patch:

>>> c = SimpleCookie('foo=33;foo=34')
>>> print c
Set-Cookie: foo=33

There should be a unit test though and something in the documentation. The keys dict should be a set instead.

See discussion in bpo-1372650.

Even if the patch is still valid there are still no doc or unit test changes.

Attached is a patch with Viraj's original fix except using a set instead of a dict as suggested by Björn. This patch also includes a test case and a note in the docs about this behavior.

Since Cookie has been moved and the code has been cleaned up somewhat between 2.7 and 3.2 I'm attaching patches for both branches.

Of course, a decision still needs to be made whether or not this should be applied; the behavior is more correct now, but I don't know if it is worth potentially breaking applications that have come to expect the old behavior. There doesn't seem to be a consensus in bpo-1372650 but I thought having a complete patch would be a good thing regardless.

Just adding the 3.2 patch

Relevant spec
https://tools.ietf.org/html/rfc6265

This patch should really be included.

As carl already mentioned, the relevant spec is RFC 6265, see section 5.4.2: "The user agent SHOULD sort the cookie-list in the following order: Cookies with longer paths are listed before cookies with shorter paths. Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times."

Currently, if the cookies are loaded with cookies.load(env['HTTP_COOKIE']) as most web frameworks do, then the cookies will be populated with the least specific or oldest values if there are duplicates. This is really bad.

Hi! Sorry, I am very new in open source...
Could you help me how can I assigned this issue for me?

@Hyper-glitch It's an open project, no preliminary assignment is required. The only thing you need is to follow the contributor's manual at https://devguide.python.org/ where conventions and processes are described.

@Hyper-glitch are you still working on this?

@iritkatriel @arhadthedev Based my last PR that waiting for core review I suggest to remove the easy tag from this issue also based on time the issue created and corresponding Core developer opinion on this issue maybe we can close it without accepting my PR.

Hi everyone,

I am not a core developer and am new to open source, but I want to participate in this issue and help resolve it (mostly out of curiosity and to start being involved in open source Python). The idea came up from a sprint at this year’s EuroPython (https://ep2024.europython.eu/sprints#cpython-core-work-on-python-314).

If I understand correctly, we want to have an up-to-date http.cookies library that conforms to https://datatracker.ietf.org/doc/html/rfc6265, whereas the current cookies library conforms to a relaxed version of RFC 2109/RFC 2965 (as seen in the documentation https://docs.python.org/3/library/http.cookies.html#module-http.cookies and in the code https://github.com/python/cpython/blob/main/Lib/http/cookies.py).

Simply changing the current behavior of http.cookies is dangerous because there are probably users who rely on the current behavior, and silently changing it can break things for them without their knowledge.

At the same time, I found that there is a library that handles cookies according to RFC 6265: https://pypi.org/project/cookies/. However, it is not part of the standard Python library. This library also refers to other implementations.

So, maybe instead of changing the current implementation, we can do one of the following things:

1. Add a link to the https://pypi.org/project/cookies/ library in the http.cookies documentation and propose using it if you want to be compliant with RFC 6265.
2. Contact the author of the https://pypi.org/project/cookies/ library and ask if we can include it under http.cookies as a new module in the standard library.

If either option makes sense to the community, I can contribute by doing this. :)