1344090 - Firefox's cookie limitations does not allow to store 150 cookies per-domain , but only for the root domain, it is confusing.

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect, P3)

Description

[xjliang2007]

Attachment: cookies after evicted for domain=reg.taobao.com

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

1. We clear all the cookies that stored by firefox, then visit page = https://reg.taobao.com/member/reg/fill_mobile.htm

2. Using js script to write 150 cookies(domain=reg.taobao.com) in the console of firefox. The js script as follows:

function setCookie(name,value) { 
    var Days = 30; 
    var exp = new Date(); 
    exp.setTime(exp.getTime() + Days*24*60*60*1000); 
    document.cookie = name + "="+ escape (value) + ";expires=" + exp.toGMTString()+";Domain=reg.taobao.com"
} 

for(var i=1;i < 151;i++){
  setCookie("name"+i,"value"+1);
}

3. check the cookies stored in firefox, found it is ok with 150 cookies in domain of reg.taobao.com

4. visit page = https://login.taobao.com/member/login.jhtml , then check cookies , found that some cookies(belong to domain=reg.taobao.com) were evicted,but those cookies have different domain with the later ones.




Actual results:

the cookies of domain=reg.taobao.com were evicted by the cookies of domain=login.taobao.com or domain=.taobao.com


Expected results:

all cookies should be kept for domain=reg.taobao.com, because their domain is different from later ones

Comment 1

[xjliang2007]

I did my test on firefox version of 50.0 , but this case also happened for 51.0

Comment 2

[YF (Yang)]

Can you provide an testcase with a different website? I encountered a variety of refuses (redirecting properly, need to be verified and http://alisec.taobao.com/deny.html, etc.) from taobao.com when take this STR, so it may be Taobao's behavior.

Comment 3

[xjliang2007]

(In reply to YF (Yang) from comment #2)
> Can you provide an testcase with a different website? I encountered a
> variety of refuses (redirecting properly, need to be verified and
> http://alisec.taobao.com/deny.html, etc.) from taobao.com when take this
> STR, so it may be Taobao's behavior.

Hi, yang
thanks for your reply. Can't you repeat my test case? The deny html indicate that your requests were intercepted by Taobao, maybe you visit so frequently. 
This confusing case can be repeated with other site. It is the same result.
For example, I first vist page=http://www.163.com and set 150 cookies in domain=www.163.com , 
then I visit page=http://mail.163.com , this page will also generate some cookies in domain of 163.com , 
but I still found some cookies in domain=www.163.com were evicted due to the same reason as I described above.
You can try this test case or you can use other sites to repeat. It is because of the cookie store mechanism, every site bears such influence.

Comment 4

[xjliang2007]

Hi, YF 
what is the meaning of your reply? I can not understand it. By the way, did your repeat my test case?

Comment 5

[YF (Yang)]

I see the limit via http://browsercookielimits.squawky.net/. But I don't know whether it is a issue, waiting for someone else to triage.

Comment 6

[xjliang2007]

Hi, YF
Did you know someone who work in firefox? Maybe I can ask him for help about this case, haha.

Comment 7

[YF (Yang)]

Any thinking?

Comment 8

[Amy Chung [:Amy]]

I will take a look at this bug.

Comment 9

[xjliang2007]

(In reply to Amy Chung [:Amy] from comment #8)
> I will take a look at this bug.

Thanks for your reply , I hope I describe the issue clearly, it makes me confusing, if it is not a bug, then what's wrong with my test case, really need your explanation , haha.

Comment 10

[AM]

We are also seeing similar issue with Firefox 52.0 32 bit version. Our application is not able to set cookie after cookie count for domain including subdomain reaches to 150, however this behavior is not consistent. 
Some domain set-cookie requests are able to evict old cookie and set new cookie but some domains set-cookie instruction is completed ignored.
Is there any algorithm to decide when old cookies will be evicted to make room for new cookie or any new flag has to be added to inforce to set cookie is every case.

One pattern is observed if there is 150 persistent cookie for domain including sub domain those can't be replaced by non-persistent set-cookie request. Those cookies are only replaced by persistent [with max-age] set-cookie request.

Can we get firefox developer attention on this. This is causing lot of trouble organization wide SSO login.

Comment 11

[AM]

we are not seeing above behavior in FF 49. In FF 49.0, cookie is getting replaced by any call irrespective of persistent nature e.g. desired cookie is being set and evicted older cookie.

Comment 12

[Shian-Yow Wu [:swu]]

If I understand correctly(based on bug 1264192 comment 104), Chrome's 180 cookie limitation is also sub-domain based.  Doesn't this kind of issue also happen in Chrome browser when cookie number reaches limitation?

Comment 13

[Shian-Yow Wu [:swu]]

> If I understand correctly(based on bug 1264192 comment 104), Chrome's 180
> cookie limitation is also sub-domain based.

To be clear, what I mean here is per-base-domain(i.e. counting google.com and all of its subdomains).

Comment 14

[AM]

In Chrome, even if we set 180 secure domain cookies, it got replaced by subsequent set-session cookie request that is not happening in Firefox.

Comment 15

[AM]

Ideal behavior could be "not to replace secure cookies" but increase allowed cookie count to next level say 200. Other way to handle it consider every sub-domain as separate domain in cookie count logic.

Comment 16

[Amy Chung [:Amy]]

Hi Josh,
I had written a testing webpage to verify the difference between Chrome and Firefox when the number of cookies per host to the maximum, and the result as below:
[Chrome]
1. Maximum of the cookies per host:180
2. Deleting algorithm
    1. If this cookie is expired
        1. Delete this cookie
    2. Otherwise, if this cookie doesn’t set secure flag and isn’t a session cookie
        1. Delete this cookie
    3. Otherwise, if this cookie is a session cookie.
        1. Delete this cookie
    4. Delete secure cookie
3. If the number of cookies to the limitation, and user set a cookie on same base domain.
    1. Chrome will remove 30 cookies and let the number of cookie reduce to 150.

[Firefox]
1. Maximum of the cookies per host:180
2. Deleting algorithm
    1. If this cookie is expired
        1. Delete this cookie
    2. Otherwise, if this cookie doesn’t set secure flag and !DomanMatch() and !PathMatch()
        1. Delete this cookie
    3. Delete the oldest cookie
3. If the number of cookies to the limitation, and user set a cookie on same base domain.
    1. Firefox will remove one cookie.

Would you give me your suggestion that we could avoid the similar bugs?
In my view, maybe we could modify the maximum and the number of deleting the cookies which are candidates.

Thanks!

Comment 17

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 18

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 19

[Amy Chung [:Amy]]

Hi Jason,
Base on Comment 16, I think we could modify the maximum and the number of deleting the cookies which are candidates.
Would you give me your suggestions?

Thanks!

Comment 20

[Josh Matthews [:jdm]]

As mentioned in an email thread, I think we should:
* increase the limit to 180 before we start evicting cookies
* implement batch eviction that brings us down to 150 again when we evict cookies
* remove our eviction heuristics that rely on path and domain checks

Comment 21

[Jason Duell]

I'm unclear on whether there's still work in this bug, or whether we fixed everything in bug 357676.  Is there still work here, and if so, what?

Comment 22

[Jason Duell]

That last comment got the bug number wrong--it's bug 1357676 :)

Comment 23

[Kershaw Chang [:kershaw]]

(In reply to Jason Duell [:jduell] (needinfo me) from comment #21)
> I'm unclear on whether there's still work in this bug, or whether we fixed
> everything in bug 357676.  Is there still work here, and if so, what?


We did all the work in bug 1357676 based on comment #20.
So, I think we can close this bug.

Comment 24

[Josh Matthews [:jdm]]

Agreed.