Skip to main content

Chrome's Omnibox, debugging web applications and web statistics

If you use the latest version of Google's Chrome browser, you may have seen this setting:



Couple of days ago, I decided to turn it on. This way, I can get instant results when I search via the omnibox. Since I never go to Google's home page, this is the only way for me to get the benefits of instant search. So I turned it on and promptly forgot about it. Fact is, I never actually thought about how it worked. Why? Because the way it works is every character you typed is instantly sent, as a search query, to your search provider. So far, that's not a big deal. That's intuitive. However, what's not so intuitive is that once Chrome detects you are typing a URL, it starts sending those requests to the webserver for the URL. So say you want to type in "http://localhost/myapplication/pageAmTesting.aspx?Id=500", the last few requests Chrome will send are:
  • http://localhost/myapplication/pageAmTesting.asp
  • http://localhost/myapplication/pageAmTesting.aspx
  • http://localhost/myapplication/pageAmTesting.aspx?Id
  • http://localhost/myapplication/pageAmTesting.aspx?Id=5
  • http://localhost/myapplication/pageAmTesting.aspx?Id=50
  • http://localhost/myapplication/pageAmTesting.aspx?Id=500
The problem is that I routinely debug web applications by attaching Visual Studio to the browser and stepping through my code. Naturally, I am expecting only 1 request to be sent (and thus trapped and debugged via Visual Studio). I also expect that request to have a query string parameter (Id) with value (5). But with that setting enabled in Chrome, I get all these extra requests that mess up my debugging session. Some of these extra requests have no query string param (#1 and #2 in the list above); some have incomplete values for the query string param (#3 and #4 in the list).

Once I realized the problem, the fix was easy (turn off the setting). But, as is my nature, I started wondering just how much this seemingly innocuous behavior of Chrome could affect the web. Now I am not a web statistics guru, but it seems to me that this could serious skew web statistics (upwards). Then I thought to myself "Tundey, you are not smarter than Google. Surely they know about this and have taken it into consideration..." But have they? Answer is yes....and no. They have because they1 added at least 1 extra HTTP request header for all those extraneous requests. The header "X-Purpose" is set to ": preview" for preview requests. Ok so they thought about it. And I figure they've probably updated Google Analytics to account for the header (i.e. if the request has that header set, ignore it since it's not a user generated request). And perhaps there's some standards body in the web analytics space that they submitted this behavior to and got their major competitors (WebTrends etc) to adopt the standard. But what about other web usage? There are other areas of the web where this could screw things up:
  • lots of unnecessary requests putting semi-useless load on servers all over the world (because the responses from those preview requests are used just for the search result listing page...i.e. only a minor portion of the entire data returned is used)
  • lots of angst for developers when their applications keep throwing unusual exceptions (in the example above, each of those preview requests will likely trigger an exception in the web application since the expected query string is missing)
  • lots of 404 errors as some of those preview requests included incomplete page names (and thus the pages will not be found)
  • what about sites that use GET requests to perform actions? Yes it's stupid to perform POST actions using GET but I bet you some sites do it.Those sites better hope Chrome doesn't send preview requests their way
So what's the solution? Here are a couple of ideas:

  • Once Chrome detects that the text being typed is a URL, don't issue preview requests. After all, if I am in the process of typing "http://localhost/myapplication/pageAmTesting.aspx", chances are I know exactly where I want to go and don't necessarily need a preview.
  • Once Chrome detects that the text being typed is a URL, continue to send the requests to the user's search provider (like it does for other non-URL text).

I did some search on the "X-Purpose" header and it looks like it's not a Chrome-specific header at all. It's also used by Safari's "Top Sites" feature.


Related articles

Comments

Popular posts from this blog

Career 101: Dunk, layup or dribble out of bounds?

Saw this on Whisper:


The way I see it, this dude has 3 options:
Reject the $55K increase and stick with his old job that he loves (dribble out of bounds)Take the $170K to his current boss and negotiate for a raise (layup)Take the $170K job, stick with it for a year and then bounce (dunk) The first option is what I call a poor person's advice. It sounds very noble...very "get a job you love and you'll never work". Well I am here to say that's bullshit (mostly). This is business; you should always get the most you can. Besides, this is a chance for this dude to change his baseline salary for future jobs. At his current job, getting that $55K will take several years because corporate America isn't going to offer you more than a token raise each year.

My advice would be to take the $170K offer to his current manager and get him/her to match it or raise his current salary. That's the layup option. It's not too money-hungry and doesn't summarily leave $5…

Strong, Likely Boy

Item # 19:

Infant. Age 1. Described as "Strong, Likely Boy" $400.00





What to do?

I recently bought one of those wireless earbuds from Amazon. I spent some time researching all the available options and finally picked this particular one. It was highly rated on Amazon 5 stars from 54 reviewers (most of them "verified purchase"). Not great but not bad. Anyway, the earbuds arrived and I found this in the box:

Hmm, OK. Very mysterious. As instructed, I sent them an email for further information. Here's what I received:

Funny thing is I really like the ear buds. Excellent build quality and thus far, great performance. They reconnect to my phone 2-3 seconds after taking them out of the case. It's easy to create a good seal...sometimes so good I get that underwater feeling one gets with noise cancelling headphones. Even without the 40% incentive, I would have written a review...that's how much I like the ear buds. But now I feel weird about doing it. I wonder how many of those 54 5-star reviews were motivated by a 40% discount.

As for the 40% discou…