One for the web team regarding load balancing

The web team recently announced a change to the way they're serving webpages on secondlife.com. One big change was the redirecting of HTTPS requests to secure-web*.secondlife.com, in order to deal with security certificates.

Unfortunately, this had a side-effect of breaking a script I wrote that automatically grabs transactions.xml in order to do some statistical work on the data. Before, I used to use wget to visit https://secondlife.com/login.php, with POST data that included my name and password in order to get a session cookie. Then I would grab the latest transactions in XML format.

Now, I seem to be getting redirected to a secure-web*.secondlife.com, and in the process, the POST data is dropped on the floor. The solution looks like it is for me to hardcode in one of the secure webserver addresses, so I'm posting to http://secure-web5.secondlife.com/login.php, or something similar. This seems like it'll work, but it makes me think of one big question:

Which server should I pick? Can I be sure that it'll stay up? Can you think of a convenient way for me to grab one dynamically? Fetching https://secondlife.com/login.php just to see which server I get redirected to sounds like a really annoying process to code.

Thanks for the question, Lex. For the time being, we're planning on keeping the structure you noted in your post - http via http://secondlife.com and https via the secure-web* links. You can link directly to any of the secure-web* links for your scripts. Until we overhaul our load balancing model - not something we have planned at the moment - these will remain accessible. I would love to tell you they'll *always* be there, but who can say what the future holds?

As for availability of the hosts, we intend to try to keep all of the hosts up all the time, of course, and replace sick hosts as soon as is practical if they give us problems.

At this moment, the best recommendation I can make is that you set up a default and backup host (or three) in your scripts so handle the "sick server" case.

~~b