 |
 |
Nice. X-Forwarded-For would also allow google to deliver availability information suitable for the actual location of the end-user. If their software chooses to pay attention to this. Which is the objection to server-side API requests voiced to me by a Google person. (By proxying everything through the server, you are essentially doing what I wanted to do in the first place but Google told me they would not allow. Ironic if you have more luck with that then the actual client-side AJAXy requests that Google said they required!) Thanks for alerting us to X-forwarded-for, that's a good idea. Jonathan Joe Hourcle wrote: > On Tue, 18 Mar 2008, Jonathan Rochkind wrote: > >> Wait, now ALL of your clients calls are coming from one single IP? >> Surely that will trigger Googles detectors, if the NAT did. Keep us >> updated though. > > I don't know what Peter's exact implementation is, but they might relax > the limits when they see an 'X-Forwarded-For' header, or something > else to > suggest it's coming through a proxy. It used to be pretty common when > writing rate limiting code to use X-Forwarded-For in place of > HTTP_ADDR so > you didn't accidentally ban groups behind proxies. (of course, I don't > know if the X-Forwarded-For value is something that's not routable (in > 10/8), or the NAT IP, so it might still look like 1 IP address behind a > proxy) > > Also, by using a caching proxy (if the responses are cachable), the total > number of requests going to Google might be reduced. > > I would assume they'd need to have some consideration for proxies, as I > remember the days when AOL's proxy servers channeled all requests through > less than a dozen unique IP addresses. (or at least, those were the only > ones hitting my servers) > > -Joe > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu