User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20060728 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20060728 Firefox/220.127.116.11 Both the front page at https://addons.mozilla.org and at least some of the pages accessed automatically by various functions in Firefox (and probably other Mozilla programs such as Thunderbird) try to set this cookie, but should not: Name: NSC_beepot-ttm Expires: After 10 minutes Essential: No (page works fine when user denies cookie) Reproducible: Always Steps to Reproduce: For all tests, make sure Firefox (or other browser) is set to prompt for all cookies and that no exception for addons.mozilla.org has been configured and no cookies for addons.mozilla.org are in the current cookie jar. (Forgetting this step could mask the bug, as with any such case). Alternative 1: 1. Go to https://addons.mozilla.org 2. You are immidiately prompted to accept the cookie. (This alternative was also reproducible with Internet Explorer 6.0 SP1). Alternative 2: 1. In Firefox 1.5.x (currently released build, as listed in User-Agent), Open Tools, Extensions. 2. Press Check for updates. 3. You are prompted multiple times about this cookie (assuming you press Deny each time). Alternative 3: 1. In that same build of Firefox 1.5.x, press Help, Check for updates 2. You are prompted about a different cookie from aus2.mozilla.org (Note this appears unrelated but is listed for completenes only). Actual Results: I am prompted to accept a non-session cookie, for alternatives 1 and 2 this cookie looks like: Name: NSC_beepot-ttm Expires: After 10 minutes Denying the cookie seems to have no ill effect indicating that the cookie serves little useful purpose. The prompt to accept a cookie is especially scary/annoying in Alternative 2 (and 3), as no explicit navigation has been performed and users should rightfully be suspicious of ANY information exchanges and security warnings when not explicitly and manually visiting a site. Expected Results: No cookie sent or set in these scenarios! The specific expiry time of this cookie (now+10 minutes) makes me suspect that this annoyance cookie is an artifact of the broken download throtling code mentioned in the Wiki pages. But this is just a hunch and may well be wrong. If this hunch is right, please consider that there are simpler (much simpler) ways to throttle heavy downloads, e.g. through apache settings and modules. To grant more bandwidth to proxies, tell apache.conf to look for the existence of the "Via:" HTTP header and classify such requests in a different "category" of users with a higher limit. Recognizing non-proxying NAT boxes is more tricky and may not be necessesary with sufficiently generous limits.
This is something put out by the load balancer used for addons.mozilla.org. Infra has more info on this. Could you guys comment? :)
(In reply to comment #0) > Name: NSC_beepot-ttm > Expires: After 10 minutes > Essential: No (page works fine when user denies cookie) > > > Denying the cookie seems to have no ill effect indicating that the cookie > serves little useful purpose. This cookie is set by the load balancer to track SSL sessions for SSL stickiness. For capacity/performance issues, the client is keeping track of the SSL session by means of this cookie instead of the load balancer doing the same. There's been some discussion on whether or not this was actually necessary, especially due to the nature of addons and how it's accessed (and how it doesn't really need to be sticky). I've disabled SSL session persistence.
Assignee: nobody → mrz
This is FIXED now, for the URLs I looked at.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.