| < Day Day Up > |
|
The HyperText Transfer Protocol (or HTTP) is a simple ASCII-based protocol that operates on the client/server principle. The protocol is a synchronous request/response in which a client makes an HTTP request through a socket and the server replies with an HTTP response through the same socket. The request and response follow a very simple format that can be simple or very complex depending upon the particular need. An example HTTP request and response is shown in Figure 15.5.
HTTP Request | get /index.html HTTP/1.1 |
HTTP Response | HTTP/1.1 200 OK Date: Wed 26 Nov 2002 11:50:59 GMT Connection: close Connect-Type: text/html <HTML> <HEAD><TITLE>Your response</TITLE></HEAD> <BODY> Here's the body of the web page. </BODY> </HTML> |
The HTTP request shown in Figure 15.5 is the simplest possible—only the request line is provided. This request includes the type of request (GET), the filename being requested (/index.html), and the HTTP version string that is understood by the requester (HTTP/1.1).
Note | The HyperText Transfer Protocol is documented under RFC 2068. This RFC can be freely downloaded and its location is provided in the Resources section of this chapter. |
The message flow is based upon a simple stream server and client (as shown in Figure 15.1). HTTP is a stream-based protocol, utilizing the TCP transport. The HTTP data flow showing the utilized Sockets API functions is shown in Figure 15.6. Note that this is a very simple scenario. Production HTTP servers (and clients) provide more robust controls.
Figure 15.6: Simple HTTP server/client data flow.
As with any other stream socket server, the server begins by creating a socket (using the socket function), binding a name to it (using bind), and then announcing its willingness to accept client connections (using listen). A call to accept then permits the server to accept new client connections.
The client (which in this case is a Web browser), creates a socket and then connects to the server using the connect API function and an initialized sockaddr_in structure, identifying the server address and port number.
Now that the client is connected to the server, the client can announce its request. To retrieve a file, the GET command is used (recall from Figure 15.5). To specify that the request is complete, the client ends the request message with a blank line. Sending the request is performed using the write call (though it could also use send; these functions are synonymous). The server receives the request through the recv function (but could also be performed using the read call).
After the client’s request is parsed, the server sends the HTTP response (see again, Figure 15.5). The response is made up of two basic parts, the response message header and the response message body. The header defines certain information that is used by the protocol, but not commonly seen by the end user. For example, the “Content-Type: text/html” tells the client that the message body should be rendered as an HTML file. The body in this case is the HTML file requested by the user (/index.html). Note again that a blank line separates the message header from the body. The write call is shown here to transfer the HTTP response message to the client, who uses the recv function to receive the message.
Finally, once the dialog is complete, the close function is used to end the session.
The HTTP server implemented by each of the discussed languages provides very basic HTTP services (the HTTP GET method). Two content types will be supported, the “text/plain” type and the “text/html” type. The content type will be determined based upon the file suffix for the file to be served. The server will provide the ability to serve files from the local file system, which are available in the subdirectory where the server was started.
| < Day Day Up > |
|