Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot include two cookies with the same name in a response #3002

Closed
stevenhair opened this issue May 14, 2018 · 7 comments
Closed

Cannot include two cookies with the same name in a response #3002

stevenhair opened this issue May 14, 2018 · 7 comments
Labels

Comments

@stevenhair
Copy link

stevenhair commented May 14, 2018

Long story short

This is similar to #1125 except that this relates to the server rather than the client.

The server cannot send back two cookies for different subdomains that have the same name.

Expected behaviour

If multiple cookies are defined with the same name but different paths/domains, both cookies should be sent on the response.

Actual behaviour

The response only includes the last cookie set

Steps to reproduce

from aiohttp import web

response = web.Response()
response.set_cookie('foo', 'cookie for the domain', domain='localhost')
response.set_cookie('foo', 'cookie for the subdomain', domain='foo.localhost')

response.cookies will only contain the second cookie

Your environment

  • Python 3.6.5
  • aiohttp 3.2.1
@stevenhair stevenhair changed the title Cannot access/delete cookies with the same name Cannot include two cookies with the same name in a response May 14, 2018
@asvetlov
Copy link
Member

I'm curious why do you need diffrent cookies for domain and subdomain?

@stevenhair
Copy link
Author

My use case is that we originally set the cookie on the subdomain, but now we need to implement our SSO feature on a different subdomain. The solution is easy: just set the cookie on domain.com instead of sub.domain.com. However, we would like to delete the subdomain cookie because letting it live on could create some interesting bugs.

My use case is pretty unusual, but I suspect that this will apply to paths as well (not that you should be using cookies with the same names in that situation, either).

I think that I've found a workaround which is to do this:

response.headers['Set-Cookie'] = 'foo=""; Domain=sub.domain.com; HttpOnly; Max-Age=-1; Path=/'

@stevenhair
Copy link
Author

It turns out that even if this worked as I expected, IE and Edge don't really care about the cookie domain when it comes to having multiple Set-Cookie headers with the same name. So even if this was changed in the aiohttp server code, it wouldn't be of much use.

I'm going to close this issue.

@asvetlov
Copy link
Member

Agree. And workaround exists, a direct setting of response headers in complex cases sounds very reasonable to me.

@nealyip
Copy link

nealyip commented Aug 7, 2018

I've encountered this problem too.
In my case I've no control on the web server, just crawl the content from it.
However, The cookies having a same name but different path were sent to the crawler.
The cookie jar used a [domain][cookie name] dict-alike structure, so that one of them was overwritten.

@asvetlov
Copy link
Member

asvetlov commented Aug 7, 2018

You always can analyze Cookie HTTP header for complex cases from a gray zone which are not handled by aiohttp.
As an alternative, you can try to make a Pull Request for respecting sent path along with name and domain but I have a feeling that the fix is complex and cumbersome.

@lock
Copy link

lock bot commented Oct 28, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs.
If you feel like there's important points made in this discussion, please include those exceprts into that [new issue].
[new issue]: https://github.com/aio-libs/aiohttp/issues/new

@lock lock bot added the outdated label Oct 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants