docs.roxen.comView this page in a printer friendly mode
DocsRoxen2.2Web Site Creator ManualBasic Concepts
Copyright  2004, Roxen Internet Software
Suggestions, comments & compliments



The most popular protocol for transfering documents over the WWW is the hypertext transfer protocol, HTTP. Typically the browser connects to the web server sending over a request for a URL, gets a response from the server and then the connection is closed. This means that the browser has to connect to the server for every thing it downloads, e.g. if a HTML page has 40 images the browser needs to make 1+40 separate requests to the server. Since there is no persistent connection between the browser and the server there is no way to know if the user is looking at the web page just sent to him, or if she continued to look at other web pages from another server.

The original intent with HTTP was to make it a "stateless" protocol, i.e. that all requests to the server is independent, from the servers point of view. In practice that means that each server response should only rely on the information given in that very request. The benefit with this approach is that it becomes easier to make an efficient server implementation that can server web pages to any number of users, since no information about the users or the requests needs to be stored once a response has been transmitted.


A stateless protocol has some interesting implications for authentication. As you perhaps know it is possible for a web server to respond with a "authentication required" response, telling the browser that it has to provide a user name and a password in order to get the contents at the given URL. This is often referred to as a login request. If the webserver accepts the user name and the password the browser remembers the user name/password pair as a valid authentication for that server, and will use them for all subsequent requests to the server. (This is an oversimplification. Read about authentication realms in RFC 2617) As a consequence there is, contrary to common belief, no logout mechanism. This is often emulated by temporary rejecting the valid user name/password causing the browser to drop the user name/password pair as valid authentication. The drawback is that the user will be presented with a new login request that she has to cancel.


Another way of overcoming the drawbacks of the stateless protocol model is cookies. A cookie is a browser variable that can be set and altered by the server. Once set the browser will include the cookie in all requests to the server, thus large cookies will "waste" a lot of bandwidth. When the server sets a new value to a cookie it also gets to decide the realm of the cookie, e.g. to which URLs the browser should send the cookie, and an expiration date, at which time the browser automatically removes the cookie. There is no defined method to remove a cookie, so that operation is often simulated by setting the cookie value to an empty string and setting the expiration time to a date that has already occured. Some browsers remove the cookie at once while others wait until the next time it is restarted. Read more about cookies in RFC 2109.


The URL of a resource doesn't necessarily give away the type of its contents, and URLs were never intended to be used for that either. Hence every response from the web server contains a content type header containing the contents "MIME type", e.g. text/html for HTML files or image/gif for GIF files. In Roxen WebServer these MIME types are usually derived from the file extension by the content type module, but scripts and other modules may choose another MIME type. MIME types are handled by IANA and a complete list of all official MIME types can be found at