Upgrading and Repairing Networks

Defining HTTP

HTTP was created to enable HTTP to transport hypertext through the Internet. Hypertext technology was first developed by Ted Nelsonand was officially known then as the Xanadu system. Xanadu was a method of creating documents on the Web, using one or more authors. One of the main features was the use of hyperlinks. Although Nelson's original ideas never caught on, they were instrumental in the development of HTML as well as HTTP.

HTTP is basically a protocol that enables the transfer of text, images, and other data between computers on the Web. Although HTML might seem to be a protocol, it is not. Without HTTP, or a similar protocol, there would be no HTML pages on the Internet. HTTP relies on the underlying TCP/IP protocols for transport through the Internet, and thus HTTP can be considered an application protocol.

Although HTTP has been in use on the Net since 1990, in RFC 1945, first published in 1996, the Hypertext Transfer Protocol (version 1, commonly referred to as HTML/1) was described by Berners-Lee and other authors. HTTP is a stateless protocol, similar to IP. It is also an application protocol because it uses TCP/IP as a transport mechanism. The term stateless means that there is no requirement for a session, such as with a TCP session in which parameters are exchanged between the endpoints of a connection (the setup phase) before data exchanges can occur. Instead, a request is sent to a server via the Net, and provided that no errors occur, a response is sent back.

HTTP Mechanics

As previously indicated, HTTP is a client/server protocol. The client application (such as a browser) sends a request to the server that hosts the information the user needs (typically a Web page). The server sends back a response. The data object the client requests is identified by a Uniform Resource Identifier (URI), such as a Uniform Resource Locator (URL). Both of these are described later in this chapter.

The data object is encapsulated by HTTP and returned to the requestor. Although HTTP commands are terminated using the combination of <CR><LF> (carriage return/line feed), the object encapsulated in HTTP (the payload) does not have to adhere to this rule. Instead, the payload (referred to as the entity-body in HTTP terminology) is determined by the type of information being transferred. For example, plain ASCII text may use the <CR><LF> combination to mark the end of a record, whereas Unix/Linux systems use just the <LF> character. And graphics files can be composed in many different formats, from GIF to JPEG, among others. The important thing to remember is that the entity-body carried by HTTP is independent of the HTTP protocol.

Most all browsers today also maintain a cache, which stores recently requested pages. At the top of your browser, there should be a button you can use to refresh a pagesend a request to the server to get the most up-to-date version of a page instead of one stored in the cache. Some pages are marked by the server so that they will not be stored in the requestor's cache. These pages are refreshed from the HTTP server each time you reference the data source.

HTTP Header Fields

HTTP header fields (not to be confused with headers that may exist in the entity-body, or payload being carried by HTTP) can vary depending on the version of HTTP, as well as the content being carried. Each HTTP header field is made up of a name followed by the colon character (:), then a space, and finally the value for the particular header. Names for fields are case insensitive.

Some examples of HTTP headers include a content type field to identify the entity-body, as well as the length of the data. Another example, which can affect the time the content from a request is cached, is the Expires field. Browsers that recommend this field will not display Web pages/data to the user from the cache after the information has expired. Instead, a new request will be sent to the HTTP server.

Many other header fields are also defined, and you can find out about them by reading the RFCs listed at the beginning of this chapter. Here, just the basics are presented, as well as the syntax for forming header fields.

Although most users are familiar with using the Address field in a browser to enter a URL, most do not know what a URL is.