I've been using the term "Web server" for a while in this blog; and now I realise that I've never defined what such an animal might be. So this is a very brief introduction to Web server technology.

I don't know, but some of you might be familiar with the idea of a file server. Basically, it's a relatively high spec computer with lots of disk space that is used for storing and retrieving files. The advantage of this is that, unlike your local hard disk drive (your C: drive, usually, for all you Windows people out there), it can be effectively backed up, centrally; can provide fault tolerant storage (e.g. parts of the disk can be corrupted or inoperable, but your data stays safe), and can make very large persistent data stores, in the form of files of one type or another, available to users - stores that are far larger than could be attached to ordinary PCs. It also allows the files it stores to be shared securely.

When you retrieve a file from a file store, your computer generally knows what program to use to manipulate the file. If you retrieve a word processing document, for example, your computer will - if it recognises the format - open it in a word processor.

So why am I talking about file servers when I promised to talk about Web servers. Well, because in essence, Web servers are just specialised file servers. They are specialised in the sense that they serve up files (called pages in Web server speak) that conform to a set of standards for Web pages. This allows a client application - a web browser - to request a certain type of page which it, the browser, can then interpret and display for the user.

At the very simplest level, all Web servers do is to serve up HTML pages that they find on their file systems by following the paths sent to them by the client browser: the URL. The URL of a web page is the address you see in the address bar of your browser, underneath the menus. For example, the URL of the page I am typing into now is http://www.blog.co.uk/admin/b2edit.php?blog=51047.

What the above URL means is that there is a document called b2edit.php in the directory called admin on the machine called www that lives in the domain called blog.co.uk. The ?blog=51047 is called the query string and tells the Web server which blog I'm editing.

Of course it's a bit more complex than that. The browser in this case is asking for a PHP page, and the Web server knows to hand off processing of such pages to the PHP application: but at the end of the day, what it sends back to the browser is HTML - even if it's been made up on the fly by another program such as PHP and never actually existed as a real file on the file system.

If you want to see what the Web server sends back, just right click on a Web page and select View Page Source - or whatever your browser says.

Generally speaking, HTML pages on Web browsers are just sent back without modification. Files such as PHP files contain instructions to a PHP processor as well as HTML markup. The Web server hands the page to the PHP processor, which modifies the page and hands the resulting HTML back to the server for sending on to the client (browser).

The pages I am writing are called ASP.NET pages. These are similar to PHP pages in that they contain a mixture of text and instructions. Until recently, these instructions could only be processed on Windows servers using Microsoft's Web server (IIS), but now, with the advent of Mono, they can be processed by other Web servers, notably Apache, using Mono as the processor. My project aims to discover whether the Apache-mono combination is as effective as the native Windows implementation.

That's probably enough for now. If you have any questions, ask away. I love this subject, so I'm only too pleased to respond to anyone else who shows even the slightest interest.