Sometimes, more often than we probably know, things don't go the way that we want them to. This is particularly true on the Web, where users are free to turn off browser features, use browsers too old or too new, and more and more developers write programs to access your content that really aren't full fledged user agents in the sense of loading images, CSS, running script, and so on.
So, what's a poor Web admin or developer to do when faced with the possibility of things going wrong that they cannot see? Well, some frankly just ignore the problem with flippant statements like "Everybody uses browser 'X'" or "Come on, how many people really do that, Mr. Expert?" We at Port80 like to feel we've moved beyond simple guessing, so let's explore a few useful techniques to help improve your knowledge about what is going wrong with your site.
Now, we know that readers are probably aware of browser sniffing scripts and the like, but we have some simple ideas that can practically applied. Let's say, for example, that you are a big fan of CSS and you (or your developers) build your site with no tables and the latest and greatest CSS rules.
Without CSS, things are going to look awfully bad, so how can we get an idea of how many people aren't seeing the latest and greatest looking pages you designed? Well, consider that a Web page is made up of many components -- a base object (typically the HTML page), many dependent objects like CSS files, JS files, images (GIF, JPEG, etc.), and media objects like Flash and so on. The fetching user agent will or will not fetch these dependent objects depending on settings, so we use this idea to set up a flare gun request to our server in order to know that things aren't going as well as we would like. Hopefully we can monitor flare request traffic in our logs or set it up so that the requests and related data are logged in a meaningful way. Essentially, flare gun request gives you the opportunity to recover from a Titanic-sinking on your Web app that you most likely are not even aware of… an opportunity if you plan ahead.
Flare 1: CSS in Distress
As a simple example, consider that we care about CSS being available. To assemble our flare, we would include something like this in our (X)HTML pages:
<DIV class="noCSS" style="DISPLAY: none">
<img scr="nocss.gif" height=1 width=1 />
</DIV>
You don't have to rely on the inline style since you would of course set the class .noCSS in a similar fashion, but we use both just to be super safe. If you are a little rusty in your CSS knowledge, the display: none will advise the CSS-aware browser not to even include this <DIV> tag in the document and thus the image fetch won’t happen at all. If the CSS is off or the user agent simply doesn't understand it, a request might be made to the server. We emphasize might because some user agents won't even bother to parse the page and try to do the dependent fetch…
You could try to catch some of these non-dependent objects by putting a link here that they might follow. Remember readers, bots love links so feel free to give them links:
<DIV class="noCSS" style="DISPLAY: none">
<img src="nocss.gif" height="1" width="1"/>
<A href="nocss.aspx">Warning: CSS Is Off</A>
</DIV>
Given this example, the bot might try to follow the link it sees solely because it doesn't apply CSS to the document. The ASPX (or other programmed page in PHP or what not) would log the access attempt, user agent and so on for your further review. You might consider modifying the image fetch in a similar manner so you don't have to hunt through logs to find the CSS-off users:
<IMG src="nocss.aspx">
In case you are overly worried about real users seeing this stuff, you can use some HTML to hide these objects, reply with a 204 no data response, or even let the warning message stay since they ought to be told they aren't seeing the latest stuff.
Flare 2: JavaScript Off SOS
For programmers, a more important problem might be a lack of JavaScript support on the client/browser side. There are a number of ways to deal with this, but the <NOSCRIPT> tag is woefully underused. The basic idea of <NOSCRIPT> is that the browser will only display the content if scripting is off or not understood, so it creates a perfect place to put a flare gun request:
<script type="text/javascript" src="ajaxlib.js"></SCRIPT> <NOSCRIPT> <img src="nojs.aspx" /> <a href="nojs.aspx">Error: JavaScript is Off</A> </NOSCRIPT>
There are more interesting ideas we have read about like using a <META> refresh in a <NOSCRIPT> to redirect someone automatically to an error page (Hat Tip to JavaScript: The Complete Reference (www.javascriptref.com) - Chapter 1), but our flare idea could also work well here.
Other Flares (Non-solar, of course)
Setting up flare requests for no plug-ins, ActiveX or Java Applets can be done in a similar fashion. Images off is, unfortunately, a difficult one. If you could session the user agent you might assume to see dependent objects within a certain period of time. However, sorry to say most folks who aren't running certain technologies are often the ones rejecting your cookies so that may not help. If you aren't blocking these types of accesses you could try to monitor for requests from a certain IP address occurring within a certain period of time. If you don't see the dependent objects being requested you can assume the user doesn't support that technology. Of course this goes back to being somewhat of a guess, particularly if you have proxies consolidating your requests.
Conclusion
At the end of the day whether you end up using flare style requests or not you should really try to add features to your site that let you know when important things go wrong. Remember blissful ignorance may be blissful, but at the end of the day you are still just ignorant.