One might think, that an application server or dynamic content creation is required to provide browser specific web pages. Why should a server or an application dynamically create a web page, if its content doesn't change from request to request consuming a lot of the server's resources? As pointed out in Chapter "Using XSLT for static web pages", you can also publish your web site by using several versions of markup languages. The key to this solution are the XML documents and the XSLT style sheets. Each version resides in its own directory. In order to choose the appropriate version, you need to run a slim line application that handles all incoming HTTP requests, chooses the right directory, reads the file and sends the web page back to the browser.
Before we go into detail, we should note that your web host needs to fulfill some requirements:
Let's call this new application to handle the browser specific web pages "browser handler". How can we guarantee that the browser handler always handles the incoming requests? Well, we need to arrange the URL in all web pages, if they refer to pages on the same server. What does it mean? One example:
This short URL requires the modification of the directory index file definition of your web server.
In order to ensure, that the browser handler is always the mediator for the appropriate web page format, all hyperlinks in the server's web pages need to be adapted to the format above.
If you or your web host operates an Apache web server and allows you to set some server configurations using .htaccess files, then the .htaccess file in the document root directory should at least contain the following line (based on the example above):
How does it work? If the web server receives an HTTP request that does not contain a file name like:
GET / HTTP/1.0
then the server launches the browser handler, because the web server looks into the .htaccess file for which default files it shall search in its virtual directories. The only entry in our .htaccess file is the path to our browser handler. Therefore, the web server launches the browser handler, if it is really there.
In order to understand the browser handler's role in case of a URL like http://www.foobar.com/?/news/20010207.html, we need to know which information the web server receives from a web browser.
The browser sends an HTTP request with a request line as follows:
GET /?/news/20010207.html HTTP/1.0
The slash in front of the question mark has exactly the same effect as in the previous example above. The web server launches the browser handler. The string on the right side of the question mark is made available by the server to the browser handler via the Common Gateway Interface (CGI) . The CGI environment variable "QUERY_STRING" carries the value "/news/20010207.html" which can be read by the browser handler. The browser handler analyses the content of the "QUERY_STRING" variable, determines the appropriate content format based on the HTTP header fields "accept" and "user-agent" and responds with the appropriate content format on the browser's request.
It's easy to proclaim that the browser handler responds with the appropriate content format. The question arises how the response shall look like. We see two solutions that we describe in the following sections:
Copyright © 2001-2003 by Rainer Hillebrand and Thomas Wierlemann