2.4 Application Layer Protocols
2.4.1 Hyper Text Transfer Protocol
The Hyper Text Transfer Protocol (HTTP) [BL+96] is a generic, stateless, and object-
oriented application-level protocol that can be used for a variety of tasks based on the request-response methodology. The light-weight protocol provides service for distributed, collaborative, hypermedia information systems. Since 1990 when the World-Wide Web (WWW) initiative decided to use HTTP, it has evolved to one of the most widely deployed application level protocols today.
Although it is currently exclusively used on top of the transport protocol TCP (see sec- tion 2.2.2), HTTP is independent of the transport protocol. It merely requires that the underlying transport protocol provides reliable service.
In practice most information systems or multimedia applications require more functionality than simple document retrieval. Therefore, HTTP allows an open-ended set of methods to be used to indicate the purpose of a request.
2.4.1.1 HTTP URLs
HTTP is based on the concept of Uniform Resource Locators (URL) [BL+94]. URLs
unambiguously identify and locate a resource in the Internet by providing an abstract identification of the resource location. Different URL formats are defined for each major class of Internet service. The first part of the URL specifies the service type, for example, FTP URLs start with ftp:, Email URLs begin with mailto:, etc.
Although the different URL types have very similar syntax and semantics, from now on the HTTP URL type is emphasized. The HTTP URL syntax is defined as follows:
http://<host>[:<port>]/<path>[?<searchpart>]
The individual tags are used as follows:
<host> specifies the Internet domain name (or IP address) of the server application (if authentification is required, the user name and password can also be encoded) <port> determines the port number of the server process. Well-known protocols have
<path> determines the location of the resource on the server. It is usually the relative path from the root directory of the HTTP server to the resource. Usually the path is used to specify a single document or script that is invoked by the request. However, the path can also be used to specify other objects (for example, directories, scripts, parameters within the server application) which are invoked, retrieved or changed. <searchpart> provides a mechanism to specify request properties. The <searchpart> can
be used, for example, to transfer [variable, value] pairs to CGI scripts14. The format
is simply: <varname>=<value>. The “&” character is used to separate multiple pairs. An example of a complex HTTP URL is presented here:
http://spock.lancs.ac.uk:1090/webaudio?method=PLAY&format=GSM
This example shows how URLs can be used to control applications that provide a HTTP interface. The HTTP request is sent to the Internet host spock.lancs.ac.uk. The ap- plication process listening on port 1090 will receive the request and processes it based on the <path> and the <searchpart> parameters. In this example WebAudio, the real-time audio streaming application developed within this work, is commanded to start streaming the audio source referenced by webaudio and to use the GSM codec as audio encoder.
2.4.1.2 Overall Operation
HTTP is a classical client-server-based request-response protocol. Clients send the request consisting of the request method, a HTTP URL, and the protocol version to the server. The server then processes the request and responds with a status line including the protocol version and a success or error code possibly followed by the requested resource in the case of a simple retrieval request.
HTTP communication is client-initiated by user agents, such as, Web browsers. A client
opens a reliable connection to the server or to some intermediate proxy15, gateway16, or
tunnel17 which imitates a HTTP server. The connection provides then a reliable commu-
nication channel for the request-response pair. According to HTTP/1.0 each transaction must use a separate connection. Thus, the server closes the connection after having sent the response.
14The Common Gateway Interface (CGI) defines a general mechanism to invoke scripts or applications
as server-side HTTP extensions.
15A proxy forwards a request towards the server identified by the URL after applying changes to the
request.
16A gateway acts like a layer above some other server(s) and translates a received requests to the
underlying server’s protocol, if necessary.
17A tunnel acts as a relay point between two connections without changing the messages; they are used
2.4. APPLICATION LAYER PROTOCOLS 61 Summarizing, each request/response can be seen as a single transaction between the client and the server. Since the server considers (and indeed sees) successive requests from the same client as being independent from each other, HTTP is said to be stateless.
2.4.1.3 Message Format
This section describes the basic format of the request and response messages according to the HTTP/1.0 specification. In earlier versions of HTTP (i.e. HTTP/0.9), much simpler requests and responses (known as Simple-Request and Simple-Response) were used. However, version 1.0 demands the more complex Full-Request format (see Table 2.5) and Full-Response format (see Table 2.6).
A HTTP/1.0 compliant Full-Request message sent from a client to a server includes the Request-Line and additional option headers fields. The optional Request-Header allows the client to pass additional information about the request and the client itself to the
server. A detailed format description is presented in [BL+96].
Full-Request = Request-Line
*( General-Header | Request-Header | Entity-Header )
CR18LF19
[ Entity-Body ]
Request-Line = Method SP20HTTP-URL SP HTTP-Version CRLF
Method = GET| HEAD | POST | extension-method
Table 2.5: Syntax of a full HTTP requests
The Method generally used within the WWW is called GET. It retrieves the resource identi- fied by the HTTP-URL (for example HTML documents, images files, etc.). If the HTTP-URL refers to an executable (i.e. a CGI script or application), the output of the application is returned as the response. The HEAD method is similar to GET except that the server returns only the meta information contained in the HTTP header of the response. The Entity-Body is simply ignored. The POST method, on the other hand, tells the destination server to accept the Entity-Body enclosed in the request as a new subordinate of the re- source identified by the Request-URL. This method is especially useful if the <searchpart> of the URL becomes too long. In this case the <searchpart> should be included in the optional Entity-Body, since some systems limit the maximum URL length.
A HTTP/1.0 compliant Full-Response message is shown in Table 2.6. 18CR = ASCII character decimal 13: carriage return
19LF = ASCII character decimal 10: linefeed 20SP = ASCII character decimal 32: space
Full-Response = Status-Line
*( General-Header | Response-Header | Entity-Header )
CRLF
[ Entity-Body ]
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Table 2.6: Syntax of a full HTTP response
The Status-Line of the HTTP response consists of the protocol version followed by a numeric status code and its associated textual phrase. The Status-Code is intended for use by programs whereas the Reason-Phrase is intended for the human user. The first digit of the Status-Code defines the class of response code (see Table 2.7). The optional Response-Header again allows the server to pass additional information about the response and the server itself to the client.
Code Description
1xx : Informational Reserved for future use
2xx : Success Request was successfully received, accepted and processed
3xx : Redirection Further action must be taken in order to complete the request
4xx : Client Error Request caused a syntax error or cannot be fulfilled
5xx : Server Error Server failed to fulfill an apparently valid request
Table 2.7: Categorization of HTTP Status-Codes
The Entity-Body is optional in both the Full-Request and the Full-Response. The Entity-Header defines meta information about the Entity-Body or, if no body is present, about the resource identified by the request URL. The most important entity header field is the Content-Type. It indicates the media-type of the data sent within the Entity-Body. The Content-Type header field is defined as shown in Table 2.8.
Content-Type = Content-Type: media-type
media-type = type / subtype *( ; parameter )
parameter = attribute = value
Table 2.8: Syntax of the Content-Type header field
Further details about currently specified media-types are defined in [RP94]. Two examples are provided to illustrate the use of the Content-Type field:
2.4. APPLICATION LAYER PROTOCOLS 63 The data in the Entity-Body are textual by nature and in particular HTML encoded. This is the standard content type for HTML documents.
• Content-Type: application/webaudio
The application media-type indicates that the data are destined for an external application and in particular WebAudio here. If an application is registered with a certain content-type, the client launches the application upon receipt of the this content-type within the response Entity-Header.
2.4.1.4 Shortcomings
An obvious flaw of HTTP/1.0 comes from the requirement that a new TCP connection must be established for every single request-response. This not only makes the performance suffer from the delay introduced by TCP’s three-way-handshake during connection establishment, but also from the fact that current implementations of TCP deploy the slow start algorithm (see section 2.2.2 for more information on TCP). Since slow start is always applied at the beginning of the communication on a new TCP connection, the performance of the request- response delivery suffers greatly. A simple solution to this problem is to support persistent connections which are kept alive for multiple transaction. Moreover, from a network point of view it need to be noted that the shortcoming of establishing a new TCP connection for every HTTP request makes the Web transfer less responsive to network congestion. TCP’s congestion control mechanisms are less effective for short-lived connections.
Another problem with respect to the protocol overhead is that HTTP is stateless. The server has no recollection of data types and properties used by the client from one request to another. Therefore, all information must be re-transmitted in every request. This is particularly a problem if HTTP is used for session control within multimedia streaming. Every time a control command is sent, the client must send all information identifying a session to allow the server that maintains the session state can associate the request with the corresponding session. Incorporating a session id as part of the HTTP protocol headers would be very useful (compare the RTSP protocol header section 2.4.2.3).
The performance problem mentioned above was one of the main issues that forwarded the
design of the next generation Hyper Text Transfer Protocol (HTTP/1.1) [F+97]. The new
protocol makes use of persistent connections between clients and servers. The connection is established prior to the first request and kept alive for the transmission of subsequent requests and responses. The new HTTP protocol also improves its predecessor with respect to the support for hierarchical proxies and caches as well as “virtual hosting” (see also [F+97]).