I just got a call from John Goodman at Netcenter who's concerned that if we ship a beta without the hack that munges home.netscape.com to home<n>.netscape.com (where n=1..32), then we could seriously impact netcenter throughput/performance. I asked him why DNS isn't sufficient to do this randomizing function (i.e. yahoo and others must rely on that), and he said he would have Andy Small call to explain. In addition to home.netscape.com, he would like to see us do the same thing for www.netscape.com (RFE).
Netcenter is planning on shipping a home pag specifically for Seamonkey. Does this affect that as well. Putting on PDT+ radar for beta1.
Jud, maybe you should take this one, and just get assistance from Gagan as necessary. He's overloaded now.
Assignee: gagan → valeski
DNS is sufficient. This is an old hack that was used in 1.0 to protect our, then, insufficient site from dying. I would be totally blown away if our current site still relies on this. We need to confirm that this is still necessary. Has Andy Small called? I'd prefer not to put this in. Also, we need to know what url will be the default one used when we ship. *That* is the host we'd be protecting against.
I am with Jud on this... How many times have we recd. data from just home.netscape.com? Why can't this be handled with a redirect based on the user-agent string?
Although a redirect is still expensive (that hasn't stopped our keyword team from sending the client through 3 redirects when you do a keyword search), it does push the solution off to the server (where it should be). Also note that a redirect solution would put all initial hits on the same server (no distribution). But, the real expense of serving out an entire page w/ graphics would be distributed. I also want to note that a client side fix is really dependent on what url we ship a beta with (as the default). If we're planning on defaulting to a page that isn't even in the www-X range, then we'll bypass the entire host distribution scheme entirely.
invalid. we're not doing this for beta which means ops has a chance to solve this on the server side.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
closing this as invalid. Agree that server side solution correct way to handle this.
Status: RESOLVED → CLOSED
You need to log in before you can comment on or make changes to this bug.