An Aside - The Hypertext Transfer Protocol as a Universal RPC Mechanism

Underlying the World Wide Web is the Hypertext Transfer Protocol or HTTP. This was orginally designed purely to serve HTML documents, so provided a simple GET of a document URL, which received a response from the receiver consisting of the HTML in plain ASCII. But it is in the nature of all good ideas to become more complicated. Why should documents simply be ASCII? Why not allow other character sets? Documents don't consist entirely of words - why not allow pictures and other forms of media? And so it came to pass that HTTP used the MIME standard (REF?) to encode the documents transferred from server to browser, allowing a range of media types and encodings. Since HTTP was now passing generic objects around, identified using the URI and typed by MIME, the current set of designers thought to themselves, ``Hey, we have the basis of a generic request response protocol which we can use for rpc, but encoded in ASCII. Let's turn the next generation of HTTP into an rpc protocol''

So, the Hypertext Transfer Protocol in its current formulation of version 1.1 [#!fielding97:_hyper_trans_protoc!#] has extended its capabilities beyond a simple protocol to transfer html documents to becoming a generic request-response protocol for the Internet. Its authors describe it as an ``application-level protocol'' which is a ``generic, stateless object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems through extension of its request methods''.

  

Figure 9.17: Basic HTTP Exchange

Like many other protocols emerging from the IETF, the protocol is based around ASCII header fields^9.1. The model is that the client sends a request to a server, possibly via one or more proxies. If the request isn't serviced by any of the intermediate proxies, then it eventually reaches the server. The server responds to the request with a response which returns via the proxies. The fields of the messages are split into four separate headers which relate to different parts of the protocol. We give a brief overview below, which is sufficient to understand the structure of the RTSP protocol; for full details the reader should go to the HTTP standard itself, in [#!fielding97:_hyper_trans_protoc!#].

The HTTP messages have a first line which contains the type of request or the response, followed by a general header, a request or response header, and an entity header. If appropriate, there is also a message body.

The first line of any request indicates the type of method;``GET'', ``HEAD'', ``OPTIONS, ``POST'', ``PUT'', ``DELETE'', ``TRACE'' are currently defined. After the type of request comes the Uniform Resource Identifier (generally a URL) upon which the request is to act, followed by the version of the protocol. The first line of any response gives the status of the request, which has the version of the protocol, a numeric code and a textual description of the response, eg numeric code 200 is ``OK'', whilst 404 is ``Not Found''.

The general header applies to both request and responses, but not to the body. They include the fields Cache-ontrol, Connection, Date, Pragma, Transfer-Encoding, Upgrade and Via.

The request header includes additional information for the request, such as the range of encodings that the client can accept, the most recent entity the client has, and the client software. Response headers give information about the age of the response, when to retry on failure and the type of server.

The entity header gives optional information about the body of the message, such as the length (Content-Length), the type of the entity (Content-Type), when it expires (Expires) and when it was last modified (Last-Modified). There may be an entity header for each of the entity bodies present.

Finally, the bodies contain the actual data associated with the request and the resource, such as the HTML page, the image, or the audio file.