27923 - home.netscape.com -> home<n>.netscape.com hack

Status: CLOSED INVALID

(Core :: Networking, defect, P3)

Description

[Warren Harris]

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).

Comment 1

[leger]

Netcenter is planning on shipping a home pag specifically for Seamonkey.  Does 
this affect that as well. Putting on PDT+ radar for beta1.

Comment 2

[Warren Harris]

Jud, maybe you should take this one, and just get assistance from Gagan as 
necessary. He's overloaded now.

Comment 3

[Judson 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.

Comment 4

[Gagan]

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? 

Comment 5

[Judson Valeski]

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.

Comment 6

[Judson Valeski]

invalid. we're not doing this for beta which means ops has a chance to solve
this on the server side.

Comment 7

[Tom Everingham]

closing this as invalid.  Agree that server side solution correct way to handle 
this.