Calling home: fatal?
Was asked if I could help solve a proxying problem this evening. My provisional diagnosis raises a couple of issues of interest, and it would be good to confirm whether my diagnosis makes sense. Any Iphone or Android users out there should be able to say whether it’s plausible.
It started with a request: did I have an iphone or ipad, or possibly Mac (the latter in case it was something Apple-specific). Users have been unable to view pages through the proxy, but we have no detailed explanation beyond “doesn’t work”. Yes I have a mac, but it’s not here: is this a problem I can go away and look at? Or, why don’t I fire up Konqueror, the KDE browser that uses the same khtml engine as Apple? What URL should I try to see if I can reproduce the error?
This is where it gets interesting. The purpose of the project is to run a reverse proxy, but to test it I had to configure it as forward proxy for Konq and navigate to a test URL. It all worked fine, but the forward proxy is a test-only setup and blocks all but a selected whitelist of sites.
OK, next tack, can I see what’s happening if I have ssh access to the proxy itself? Trafficserver’s logs are in squid format (with which I am unfamiliar) and show
ERR_CONNECT_FAIL when the errors occur. Looking that message up, I find it should just mean Trafficserver was unable to contact the origin server. By about this time it’s also been established that Android clients have the same problem.
Reading the log, I’m guessing the clients having trouble are trying to “phone home”, so to test this I generate a couple of requests using Lynx through the proxy: one to a proxied site, the other to Google. This confirms my suspicion: the google request (which is blocked) generates precisely the log entry associated with failed requests. It also helps clarify my reading of the squid-format logs, and confirms that the iphone and android clients’ failed requests are in fact to Google URLs.
So my question to iphone and android users: would a failed call-home request (to Google) throw an error that would prove fatal to a regular page loading from elsewhere? That seems rather bizarre, though not really more so than Google maps/satnav refusing to work at all without a live data connection.
If that is indeed the problem, it still doesn’t explain why the problem should arise in normal use, when it’s a reverse proxy and the google connection is direct. Looks like either the problem is in fact on someone else’s network (combined with dumb browser design), or the messages seen in Trafficserver’s logs are a complete red herring and unrelated to the problem. Hmmm.
Posted on August 14, 2012, in google, trafficserver. Bookmark the permalink. 2 Comments.
I’m an iPad user, and I’d like to help… but I have no idea what you’re talking about. You lost me at “reverse proxy”. Then came “phone home”, which obviously doesn’t mean what it looks like, and at that point you might as well be talking Basque.
One comment: Google maps and its live connection fetish makes perfect sense in the context of Google’s game plan, which is to persuade everyone to keep everything online. They go out of their way to make it hard to do anything without an internet connection. I realised this a couple of years ago when testing a website in Chrome: uniquely among browsers, Chrome refused to load material (using Ajax) from a local drive source – the files had to be stored on a web server before it would even attempt to load them.
Today’s update: we now suspect the issue is on a particular mobile provider’s network. It’s in Canada. We’ve had other iphone users from elsewhere confirm they don’t see the original problem.
The original blog piece was techie, because only someone techie enough to read it would be likely to be able to help without running specific tests, details of which don’t belong in a public blog. Sorry if it was unnecessarily obscure.