Now I'm wondering about the architecture of LC's servers. Likely they have more than one server, and perhaps different servers get the data at slightly different times.
Since my last post on this I have done some poking around regarding this, without being a registered API user. I found no interesting headers from api.lendingclub.com while they were in the process of delivering my 401 unauthorized responses.
api.lendingclub.com resolved _every_ time for me to 216.115.73.155. That belongs to this subnet:
Lending Club LENDINGCLUB-73 (NET-216-115-73-144-1) 216.115.73.144 - 216.115.73.159
SWITCH Communications Group LLC SWITCH-COMMUNICATIONS (NET-216-115-64-0-1) 216.115.64.0 - 216.115.95.255*.144 to *.159 is quite a tight block. And this is obviously not Edgecast and obviously not where their site is being served from. It could be that complex in Nevada or wherever. (Zach once mentioned the URL to their employee test site, might be interesting to see that falls in the same subnet.) No matter. The point is, you're not going to get anywhere here looking at IPs. The best you could hope for is try all 16 (14? whatever) IPs in that range and see if anyone else answers to the virtual host api.lendingclub.com. You could find a spare server which is more "lively", or you might even find the origin which is being proxied. Likely not.
If they were using Edgecast for the API requests I might have some suggestions. Because the Edgecast crap definitely _did_ have a timewarp, no doubt about it. But here, they still could be handing off the requests to separate machines and you'd never know it because the HTTP headers are lean & mean and give no clues.
You guys are kinda behind, thinking about all this stuff just now. I'm sure the institutional guys here on this forum have been at this for years. It's too bad I never had reason to get into it; it might have been fun.
