Terry J. Reedy <tjre...@udel.edu> added the comment:
This tracker is for modifying the cpython distribution -- the interpreter,
stdlib, doc, and other associated files. Questions about using cpython and 3rd
party libraries like aiohttp should be directed elsewhere.
So, the relevant question here is whether http.cookies has a bug. I reproduced
the reported behavior in 3.7.0b1.
>>> from http.cookies import SimpleCookie
>>> sc = SimpleCookie()
>>> sc.load('LOGIN_SESSION=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT;
>>> path=/; domain=.etoday.co.kr')
<Morsel: LOGIN_SESSION=deleted; Domain=.etoday.co.kr; expires=Thu, 01-Jan-1970
00:00:01 GMT; Path=/>
>>> sc.load('LOGIN_SESSION=18676-0.53621000; path=/; domain=.etoday.co.kr')
<Morsel: LOGIN_SESSION=18676-0.53621000; Domain=.etoday.co.kr; expires=Thu,
01-Jan-1970 00:00:01 GMT; Path=/>
The Morsel created in the first call is used in the second call because
_parse_string ends with
assert tp == TYPE_KEYVALUE
rval, cval = value
self.__set(key, rval, cval)
M = self[key]
and __set begins with
M = self.get(key, Morsel())
M.set(key, real_value, coded_value)
dict.__setitem__(self, key, M)
Is this a bug? I know little about cookies, but
4.3.3 Cookie Management
If a user agent receives a Set-Cookie response header whose NAME is
the same as a pre-existing cookie, and whose Domain and Path
attribute values exactly (string) match those of a pre-existing
cookie, the new cookie supersedes the old. ..."
I don't know if pre-existing means 'previous session', 'previous server
response', or 'previous header'. I have no idea if duplicate cookies in the
same response is even legal. Even if it is, the server would do better to not
do so or explicitly give a new expires date. And if we do
make a change, we might limit it to future versions.
David, what do you think? Close as 'not a bug' or 'fix'?
nosy: +r.david.murray, terry.reedy
versions: +Python 3.8 -Python 3.5
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list