News Outline Schedule Tutorials Project Tools Links

1: What is a Server?

A server is a program which runs on a computer - any computer - and waits for a client program to ask it for something. Upon recieving a request, the server program will send information back to the client program. In the case of the Web Server, the program would be Apache, IIS, or any of a number of other web servers available. The client program for the Web Server would be Netscape, Internet Explorer, Lynx, or one of the many other Web Browsers available. The protocol that the Web Server and the Web Browser use to communicate with eachother is called HTTP. It consists of specially formatted strings of text being sent back and forth between the Web Server and the Web Browser.

2: What does the Browser do?

When the Browser requests some information (which could be a web page, a picture, or even a sound file) from the web server, it first sends a request to the server - a minimal request for a file with the URL http://www.potato.com/file.html would look something like this:

GET /file.html HTTP/1.0

The request above is fairly simple - the Browser wants to GET a file from the server, and the server can find it at /file.html, and the lowest version of the HTTP protocol that the Browser will accept is version 1.0. After the GET request, a blank line is sent by theBrowser to say that it is finished making it's request, and then the Browser will wait for the Server to send back a response. The important thing to note about the request shown above, is that it is minimal - most browsers will send much more information than that, telling the Server what sort of files they are able to accept, what brand of Browser is being used, and even what Operating System is running on the viewer's computer. A typical request for a web page would actually look more like this:

GET /file.html HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: www.potato.com Connection: Keep-Alive Cookie: myID=gimmemyfile;lastvisit=81424975234

As you can see, there is a lot more information provided here, including what the name of the machine the file was requested from, and any cookies that happen to be stored in the Browser for this web site. This page will show you the Request Header lines that the web browser you are using right now provides.

One important thing to note in this case is that the version of the HTTP protocol is different here - it's the HTTP/1.1 protocol. The only change between 1.0 and 1.1 is that the 1.1 protocol also requires a Host: line, so in HTTP/1.1, a minimal request would instead look like this:

GET /file.html HTTP/1.1 Host: www.theserver.com

3: What does the Server do?

Web client/server interaction

Once the Web Server has recieved a request for a web page, it will decide what information to send back to the Browser, and then it will sent it, in two parts - first an HTTP Header, and second, the file, or web page. A Minimal HTTP Header looks like this:

HTTP/1.1 200 OK Content-Type: text/html

The first item in the Header tells the web browser what version of the HTTP protocol the server speaks - this should be at least the value that the browser speaks, or there may be communication errors. It is for this reason that some new web browsers have dificulty getting pages from very old web servers, as some browsers, such as IE 5 require HTTP/1.1, and an old server which only handles HTTP/1.0 may send it header commands which have been altered in the newer version, and the browser does not include support for the older style of command. Additionally, the number in the first line indicates what the status of the request was - if it was successfull, then the number will be 200 - if the file asked for was not found, it will be 404. If the web browser made a request that the server did not understand, then the number will be 400. There are many other number codes, which all explain different errors or states for the request. The following are some of the more common HTTP Response codes:

Code Meaning
200 OK.
201 Created.
202 Accepted.
204 No content.
301 Moved permanently.
302 Moved temporarily.
304 Not modified.
400 Bad request.
401 Unauthorized.
403 Forbidden.
404 Not found.
500 Internal server error.
501 Not implemented.
502 Bad gateway.
503 Service unavailable.

Detailed information about these codes, as well as a full listing of all of the valid codes can be found here.

The rest of the lines in the HTTP Header each tell the Browser something about the web page, or the server which is providing it. The most important of those lines (and the only one other than the first which is actually required,) is the Content-Type: line, which tells the web browser what kind of information it is about to recieve. The type for a web page would be text/html, and the type for a jpg image would be image/jpeg. Since there are well over 200 individual types, they will not be listed here. The first part of the type, before the slash, is the main media type, and can be one of the following:

The HTTP Header will usually include many other lines, specifying things like new HTTP cookies to be set in the web browser, the date/time of last modification for the file, and what kind of web server is being used. If a web browser recieves a header line that it does not understand, then it will typically ignore it, so if you made a web server which had a new header line called Wobbly:, the web broser would just ignore it, and render the page normally as long as it got the two important lines. Here is an example of a much more complete HTTP Header from another web server:

HTTP/1.1 200 OK Date: Thu, 27 Nov 2008 23:37:18 GMT Server: Apache/2.0.48 (Unix) PHP/4.3.4 mod_ssl/2.0.48 OpenSSL/0.9.7c FrontPage/5.0.2.2635 X-Powered-By: PHP/4.3.4 Last-Modified: Tue, 23 Jan 2007 15:45:51 GMT Content-Type: text/html; charset=ISO-8859-1

The last line of the HTTP Header is always a blank line, so that the web browser knows that the requested file is about to start, and that it should begin loading it into whatever program or function is needed to deal with the data.

4: What is a "Secure" server?

A secure web server is one which is able to make encrypted connections with web browsers to send and recieve data privately, so that it can not be intercepted and read by other people on the internet. It is important to note that a secure web server's only requirement is that the data being transmitted between you and the server is kept private - this does not mean there is any other special protection on the server in question.

Encrypted transmissions between your web browser and the web server are very important when performing any kind of financial transaction or other exchange of information which needs to be kept private - regular web transactions on the internet can be intercepted and snooped on by malicious users with tools called "packet sniffers", which allow them to watch other people's data passing by them on computer networks. Thus, if you are ordering a product from a website, and you send them your credit card information through a normal (not secure) server connection, one of those people would be able to see your credit card information passing by, write it down, and then buy things for themselves using your credit card. With an encrypted connection, the browser and the server modify the data passing between them so that people eavesdropping on the internet will not be able to read it, just like in the diagrams below:

Unencrypted: [browser] => 0913-431-4625-1732 => [server]
Encrypted: [browser] => !@#$%!SXR$@GVRF*( => [server]

You can tell if your browser has made a secure connection to a web server in two ways - first, the URL for a secure web connection always begins with https instead of just http. (The additional "s" stands for secure.) Second, your browser will show a visual indicator that the connection is a secure one - older browsers such as Netscape would show a small lock icon like this: # in the status bar at the bottom of the page. Modern browsers instead show additional information highlighting the domain name from which the secure page originates, as well as often adjusting the colour of the location bar to highlight the fact that the connection is via https. A good place to go to see an example of this is a typical banking website, like any of the following: