Browser Detection using SSI

Server Side Includes

When a user with a web browser looks at a simple web page the process followed goes something like this: The browser sends a request to the 'web server' software running on the computer hosting the website for the page. This 'web server' software will then take a copy of the page requested, and simply send it to the browser for the user to view.

Many additional technologies however, exist to alter this scenario and provide a more interactive service to the user. For example, these days a user can quite easily check the availablility and price of train or aircraft tickets and pay for them, giving a delivery address for the tickets to be sent to. This level of service will make use of a number of these technologies.

One of the simplest technologies though, is called 'Server Side Includes'. This is the simplest form of 'parsed' HTML. This means that the HTML file (the file containing the description of the web page) will be looked through by the web server software before it is sent to the users browser. Whilst looking through the file, the server may make some changes to the file, depending if there are any special commands in there which the web page author wrote when the page was being designed. Generally the command itself is also removed so that the user does not see it in the final page. Usually, the filename extension is changed from .htm or .html to .shtml to indicate that it needs to be parsed. If you look up at the address bar in your browser now, you will see that the extension of this page's file is .shtml, indicating that it is parsed by the web server. One of the simplest examples of a server side include command is the #include. This might appear in the web page file as:

<!--#include file="footer1.html" -->

When this command is executed, the web server will take the contents of another file on the webserver and insert it into the requested page, at the position of the command. This might be useful for example if many pages on the website shared a common 'footer' or bottom section of the page. The author could keep this as a seperate file and have a #include statement in each of his main pages. This is what I do here on my site as I include the date of the last upload to my web server in the last line. It would be much more tedious to have to make alterations to every page on the site before each upload. This command is similar to a #include in the C programming language.

Using #echo and HTTP_USER_AGENT

Another server side include command is the #echo command. This will insert the value of a special SSI variable or environment variable into the web page. The particular one we are interested in is the HTTP_USER_AGENT variable. So to display this we can use the command:


For your browser, viewing this page now, assuming that this page has not been cached by an intermediate system, gives us the following result:


This usually contains some information about your operating system and browser, and we can examine the result, comparing against some reference values we can obtain in advance from a range of browsers and operating systems. The following table gives a small number of examples from different browsers running on Windows 2000 and GNU/Linux:

Browsers and their HTTP_USER_AGENT Values
Browser Operating System HTTP_USER_AGENT
Internet Explorer 6.0 Windows 2000 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
Internet Explorer 5.5 Windows 2000 Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)
Opera 6 Windows 2000 Opera/6.0 (Windows 2000; U) [en]
Opera 5 GNU/Linux Opera/5.0 (Linux 2.4.7-10 i686; U) [en]
Mozilla 0.9.7 Windows 2000 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221
Mozilla GNU/Linux Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20010901
Netscape Communicator 4.79 GNU/Linux Mozilla/4.79 [en] (X11; U; Linux 2.4.7-10 i686)
Netscape Communicator 4.78 GNU/Linux Mozilla/4.78 [en] (X11; U; Linux 2.4.7-10 i686)

Some browsers are capable of impersonating other browsers, and so the value returned might be misleading.

It is possible to read the HTTP_USER_AGENT value of visiting browsers, and store the values in a database so that a graph can be constructed of the frequency of visits by different user agent values. There are examples of this on the internet, and I shall post some examples soon.

Notice that the user agent value for IE6.0 and IE5.5 above have the strings Q312461 and T312461 included respectively. This indicates that a particular security update or 'HotFix' has been applied to the web browser. This may or may not be present on other machines. This means that more than one unique string can identify the same Browser and Operating System combination.

Determining Your Browser

By examining the values of user agent in the table above, we can come up with an algorythm or method of deciding which browser and operating system a user has. Then we can use some slightly more complicated 'server side includes' to add in different pieces of text to a web page depending on the findings of our algorythm, based on its inspection of a visitors user agent value. For your browser, using a straightforward algorythm we come up with the following assessment, starting with your user agent value again:


Analysis of your browser
Item Analysis
Operating System [an error occurred while processing this directive] [an error occurred while processing this directive] Microsoft Windows NT 4
Browser [an error occurred while processing this directive] [an error occurred while processing this directive] Internet Explorer 6.0

This assessment makes use of the additional Server Side Includes: #if, #elif, #else and #endif. These form a conditional structure just the same as in most programming languages. Here is the code used. It can be copied and pasted into the BODY section of an HTML file:


Dont't forget that the html file needs to indicate to the web server software that it should be parsed. This is usually achieved by renaming the file with a .shtml extension. Alternatively, implementations on a Unix like system can also indicate this by setting the execute permission of the file to active.

This last step in the process, using the #if, #elif, #else and #endif statements, is not a universally supported part of server side includes. It certainly works on the Apache web server, which is the flavour of server used by my ISP, but it does not appear to work on Microsoft's IIS.

It would make sense to test code like this out at home before deploying it on your website, as this will save repeated uploads if you need to make alterations to get it working right. The Apache webserver (called 'HTTPD') can be downloaded from their website at http://www.apache.org, and quite amazingly a windows '.msi' download is only 2Mb in size. It is a well known statistic that over 50% of the web servers on the internet are running Apache.

One other small point to be aware of is that because each web page with server side includes needs to be parsed by the web server, it may take a little longer for the page to get sent back to the requesting browser. How much of a difference in practise this might make would need to be determined by testing.

© Copyright  Piers Pettman - This page last updated 08 July 2006
Accessibility |  Test HTML |  Test CSS |  Home |  Site Map

W3C CSS Compliancy Logo W3C HTML 4.01 (Strict) Compliancy Logo