Karthikeyan Singaravelan <tir.kar...@gmail.com> added the comment:

Also looking at the docs for different frameworks like 
[Flask](http://flask.pocoo.org/docs/1.0/api/#flask.Response.set_cookie) and 
[Django](https://docs.djangoproject.com/en/2.1/ref/request-response/#django.http.HttpResponse.set_cookie)
 they recommend setting Domain attribute only for cross-domain cookies.

>From Django docs

> Use domain if you want to set a cross-domain cookie. For example, 
> domain="example.com" will set a cookie that is readable by the domains 
> www.example.com, blog.example.com, etc. Otherwise, a cookie will only be 
> readable by the domain that set it.

When there is no domain specified then the frameworks seem to set the cookie 
only for the host only as per [RFC 
6265](https://tools.ietf.org/html/rfc6265#section-5.3). So domain attribute is 
set all the time and it's just that if the domain attribute is set explicitly 
by the server with the set_cookie function in the frameworks then the cookiejar 
has domain_specified set along with dot prefixed for the domain enabling 
stricter validations. I don't know about the metrics of setting the domain 
attribute vs not setting it. Checking with a simple Flask app and set_cookie 
without domain parameter the cookies are passed to suffix domains. With domain 
passed to set_cookie has dot prefixed and the cookies are not passed to suffix 
domains.

I also looked into other implementations

* aiohttp - uses cookiejar but has custom domain checks and update cookie 
methods at 
https://github.com/aio-libs/aiohttp/blob/49261c192ff225372dffb39056c3c311714b12c5/aiohttp/cookiejar.py#L141
 . Thus it's not affected when tested.
* golang implementation - 
https://github.com/golang/go/blob/50bd1c4d4eb4fac8ddeb5f063c099daccfb71b26/src/net/http/cookiejar/jar.go#L123

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to