Java Server Pages

HTTP Request Model

HTTP Request Model
HTTP Request Model Tejas Sawant

The specification describes HTTP as a stateless request/response protocol whose basic operation is as follows:

  • A client application, such as a Web browser, opens a socket to the Web server’s HTTP port (80, by default).
  • Through the connection, the client writes an ASCII text request line, followed by zero or more HTTP headers, an empty line, and any data that accompanies the request.
  • The Web server parses the request and locates the specified resource.
  • The server writes a copy of the resource to the socket, where it’s read by the client.
  • The server closes the connection.

A key consideration is this model is stateless. This means in handling a request, the Web server doesn’t remember anything about previous requests from the same client. The protocol is simply a request and a response. Obviously, this imposes limitations on application programming, which typically requires a great deal of back-and-forth conversation, as well as complex objects that must be initialized and have their state maintained. The way around this is to have the server assign an identifier to the session represented by a set of client requests and to have the client remember the identifier and supply it to the server with each request.

Connecting to the Web Server 

A Web server operates by listening for requests on a particular well-known port number, usually port 80, although any available port can be used. If a Web server listens on a different port, URLs that refer to this server must include a colon and the port number immediately after the server name. For example,

refers to an HTML document known to a Web server running on the host on the default port 80. If the server is running on port 4311 instead, the URL looks like following

A client, such as a Web browser, initiates an HTTP request by opening a TCP/IP socket to the Web server port and then opening input and output stream over the socket. In Java terms, this would amount to a few lines of code:

Socket socket = new Socket(“”, 80);
InputStream istream = socket.getInputStream();
OutputStream ostream = socket.getOutputStream();

The parameters required to open the socket are the Web server hostname and the port number. The server hostname is extracted from the URL, while the port number is either implied or also extracted from the URL. The output stream is used to send HTTP commands to the Web server; the input stream is used to read the response.

Sending the HTTP Request

Once the socket connection is made, the Web browser writes an HTTP command to request the document. A request has up to four parts.

The first part is the request line. This consists of three tokens, separated by spaces: the request method, the request URI, and the HTTP version. The following shows a typical request line: 

GET /index.html HTTP/1.0

In this example, the request method is GET, the URI is /index.html, and the HTTP version is HTTP/1.0.

The HTTP specification defines eight possible methods, shown in the following

1GETA simple request to retrieve the resource identified in the URI.
2HEADThe same as GET, except the server, doesn’t return the requested document. The server only returns the status line and headers.
3POSTA request for the server to accept data that will be written to the client’s output stream.
4PUTA request for the server to store the data in the request as the new contents of the specified URI.
5DELETEA request for the server to delete the resource named in the URI.
6OPTIONSA request for information about what request methods the server supports.
7TRACEA request for the Web server to echo the HTTP request and its headers.
8CONNECTA documented but currently unimplemented method reserved for use with a tunneling proxy.

The second token on the request line is the requested Uniform Resource Identifier (URI). This is the URI of the document or other resource being requested. For all practical purposes, this corresponds to the URL without the leading http:// and hostname. In the example of, the request URI is /index.html

The last token on the line is the HTTP version. This indicates the highest level of the HTTP specification the client application understands. The allowable values are HTTP/1.0 and HTTP/1.1

After the request line come any request headers. These are key/value pairs, one pair per line, with the key and value separated by a colon (:). After the last request header is written, an empty line consisting of only a carriage return and line feed is sent. This informs the server that no more headers follow. Even if no headers exist, this empty line must be sent, so the server doesn’t look for any more headers. Request headers to inform the server further about the identity and capabilities of the client. Typical request headers might be

  • User-Agent              The vendor and version of the client
  • Accept                      A list of content types the client recognizes
  • Content-Length       The number of bytes of data appended to the request

Server Acceptance of the Request

When a client connects to the Web server’s listening port, the server accepts the connection and handles the request. In most cases, it does so by starting a thread to process the request, so it can continue to service new requests. Handling the request means different things depending on the URI. If the URI represents a static document, the server opens the document file and prepares to copy its contents back to the client. If the URI is a program name, such as a CGI script, servlet, or JSP page, and the server is configured to handle such a request, the server prepares to invoke the program or process.

The HTTP Response from the Server

The server processes the request, the result is the same—an HTTP response. Similar to a request, a response consists of up to four parts:
a status line, zero or more response headers, an empty line signaling the end of the headers, and the data that makes up the request.

The status line consists of up to three tokens: 

  1. The HTTP version. Just as the client indicates the highest version it can understand, so the server indicates its capabilities.
  2. The response code. This is a three-digit numeric code that indicates whether the request succeeded or failed and, if it failed, the reason why.
  3. Optional response description. which is a human-readable explanation of the response code.

A typical HTTP response status line looks like this 

HTTP/1.0 200 OK

which indicates a successful retrieval of the requested document according to the 1.0 level of the HTTP specification.
After the status line comes the response headers, with an empty line as the delimiter. Like request headers, these indicate the capabilities of the server and identify details about the response data.
The last part of the response is the requested data itself, typically an HTML document or image stream. After the data is sent, the server closes its end of the connection.

Source :- JSP: The Complete Reference By Phil Hanna