Closed Bug 590611 Opened 10 years ago Closed 10 years ago

Raise cookies per basedomain limit to 150

Categories

(Core :: Networking: Cookies, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+
status1.9.2 --- .11-fixed

People

(Reporter: dwitte, Assigned: dwitte)

Details

Attachments

(1 file)

We're starting to run into problems with the 50 limit being too low. The Chrome guys agree that we should raise it to 150.
This should block 2.0, since it's a problem now, and we want behavior to be consistent between browsers.
blocking2.0: --- → ?
Assignee: nobody → dwitte
Attached patch patchSplinter Review
Attachment #469266 - Flags: review?(sdwilsh)
We should consider landing this on the older branches as well if we're going to change it. If sites expand into the new limits that will start on a particular calendar date and extend into the future, not be based on what version the user happens to be running.
Only to versions that have the soft global limit though. When did that land?
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/af278cec894d

7/20/09 on 1.9.2. Agree we should land there too.
To be clear, for anyone reading along: the reason the limit is too low is that, when we changed the limit to mean "per base domain" instead of "per host", we caused trouble for sites that rely on being able to set a bunch of cookies on different subdomains. Like Google.

We still want the limit, but it's not as important now that we have our new purging algorithm -- we've prevented the kind of attack where a malicious site can log you out of everything; the worst you can do is cause the browser to take up a bunch of memory and disk.
Comment on attachment 469266 [details] [diff] [review]
patch

> // default limits for the cookie list. these can be tuned by the
> // network.cookie.maxNumber and network.cookie.maxPerHost prefs respectively.
Is this comment still correct?  We have four defaults here.

r=sdwilsh
Attachment #469266 - Flags: review?(sdwilsh) → review+
Comment on attachment 469266 [details] [diff] [review]
patch

Looking for approval -- we want branch to be consistent with trunk here, so behavior is uniform.
Attachment #469266 - Flags: approval1.9.2.10?
(In reply to comment #7)
> Is this comment still correct?  We have four defaults here.

Yeah, it's correct; I could mention the purgeAge pref too, though.
blocking2.0: ? → betaN+
http://hg.mozilla.org/mozilla-central/rev/a02aee4f7197

Still need a branch landing here.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attachment #469266 - Flags: approval1.9.2.11? → approval1.9.2.11+
You need to log in before you can comment on or make changes to this bug.