HTTP Requests and responses as I see it
No Comments
Written by Robert on April 3, 2008 – 3:18 am
HTTP/1.1 remains a relatively simple request–response protocol used for communication between an active client and a passive server. The client initiates activities by submitting a request.
There are a small number of request types (‘Get’, ‘Post’, ‘Put’, ‘Options’, …); most include a resource identifier and supplementary data. Usually, the client submits its request by opening a TCP/IP connection to the actual machine that hosts the server.
However, it is possible that a client may open a connection to a proxy machine and send it the request; the proxy machine then acts on behalf of the client, opening a connection to the real server. On the real server, a ‘web server’ program will read the request. A small fraction of the requests are for information about the capabilities of the web server; the web server responds to these requests itself. Most requests are for ‘resources’ that exist on the server (a resource might be a data file, or the results from an operation that the server machine can perform).
The web server may respond to a resource request with an initial response message indicating that supplementary data are needed; for example, a name and password might have to be supplied. The client would send such supplementary data over the open TCP/IP link. Once any preliminary negotiations are complete, the web server handles the actual request. The web server may process the request, generating the response data and the response header. Often the web server delegates the handling of the request to a separate process; this separate process will generate a part of the response header and the response data. The output from the separate process gets routed back via the web server that completes the header and sends the HTTP response message back to the client.
In the HTTP/1.0 protocol, the server closes its end of a TCP/IP connection once it has sent its response. This may result in quite inefficient processing of requests. A typical HTML page contains links to images and to stylesheet files. The client browser that parses the HTML will find these links and must download these files before it can display the page to the user. Consequently, the browser must make new connections to the server for each of the files. The opening and closing of a TCP/IP connection has a significant cost and takes time. If each file is transferred through a separately established connection, performance suffers. It is of course possible for a web server to keep open the connection to the client after returning the response to the first request. It can do a blocking read with a timeout on this connection; if no additional request data are received before the timeout occurs, the connection can be closed.
If the client browser can handle such an open connection, it can submit a request for an image file or stylesheet file over the same connection. Client and server have to coordinate their activities to make this work. Some HTTP/1.0 implementations supported a Keep-Alive request header; this header was sent if the client was capable of using the open connection. Reuse of a connection is a standard feature in HTTP/1.1; though it is controllable by the participants. A client can specify in a request header that it wishes that its connection be closed after the first response; a server can indicate in a response header that it will be closing the connection once it has completed its current response.
Popularity: 33% [?]
