How do Web clients and Web servers communicate together?

One of the protocols in the application layer of the OSI protocol stack is Hyper-Text Transfer Protocol or HTTP for short. This is the standard that the Web client and Web server use to communicate with each other. If we think back to client-server architecture, Web browser acts as the client and the Web server as the server. Browser sends a request to the Web server and server processes the request and returns a response to the client. Client's request in this case is in ASCII format, however response from the server is much more varied. Remember that browser could be requesting web pages that consist of not only text but also images, audio, and in all hyper-media content. Furthermore some of the content may use other applications such as Word, Excel, PDF Reader, etc to display the content. Response from the server therefore is in Multipurpose Internet Mail Extensions (MIME) format. This basically means that content that comes back from the server indicates what application should be used to view it.

Hyper-text facility allows one to encode the URL of a Web resource in an object. This object could be a piece of string in the text, or an image. When object is clicked, the embedded URL is transferred to the browser and consequent request is made to the server. It is this capability that prompts the use of HTTP as communication standard for the Web.

An HTTP request-response life cycle is that

• client requests connection to the server
• server acknowledges the connection
• client sends the request
• server processes the request
• server sends back the response.

What is the general format of a HTTP request? What is a URL?

One element of HTTP request is "method-name". What are the different methods? What do they do?

http://www.w3c.org/ is a good place to start for finding the answers. A thorough explanation is also presented on page 41, E-commerce by Chan, ....

Going back to the request-response life cycle, a connection is established at the beginning. This connection is closed after server responds to the request. In essence what this means is that in case client makes a second request, server has no recollection of who the client is and of the client's previous request. We say HTTP is stateless. Web was originally conceived to be the platform on which researchers would publish scientific documents and articles. Such application requires the architecture to store resources and to host services for publishing those resources. Clients would make requests for those resources and server would retrieve the required from storage and serve it to the client. Keeping state is not a requirement for such an application and the architecture of Web was therefore not designed to keep state.

Doing business online however does require keeping state. Server needs to distinguish between the clients. A good example of when state management becomes essential is the application of virtual shopping cart. Server needs to maintain that the content of a shopping cart belong to one client and one client alone while managing connections and potential shopping carts for a number of clients simultaneously.

What are the different methods for keeping state?

How does the system architect decide on a method for keeping state?

Food for thought:

What is the general format of server response?

What privacy issues can you think of when you keep state?