HTTP 1.1 Vs 1.0

HTTP 1.1 Vs 1.0

HTTP is acronym for hyper text transmission protocol. It is an application layer protocol for distributed, collaborative hypermedia information system. It 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 (commands). A feature of HTTP is the typing of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred to as HTTP 1.0.

This article would give you a profound comparison between HTTP 1.0 and HTTP 1.1.

The first version of HTTP, referred to as HTTP 0.9, was a simple protocol for raw data transfer across the Internet. HTTP 1.0, as defined by RFC 1945, improved the protocol by allowing messages to be in the format of MIME-like messages, containing Meta information about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation of incompletely-implemented applications calling them HTTP 1.0 has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.

The HTTP 1.1 protocol is the product of four years of research and debate among a broad group of Web researchers and developers. HTTP 1.1 is based upon the same technology as HTTP 1.0 but it has numerous advantages over its predecessor. We discuss the differences between HTTP 1.0 and HTTP 1.1, as well as some of the rationale behind these changes. HTTP 1.0 evolved from the original 0.9 version of HTTP which is still in rare use. The process leading to HTTP 1.0 involved significant debate and experimentation, but never produced a formal specification. The HTTP Working Group (HTTP-WG) of the Internet Engineering Task Force (IETF) produced a document that described the common usage of HTTP 1.0, but did not attempt to create a formal standard out of the many variant implementations. By any reasonable standard, the HTTP 1.0 protocol has been stunningly successful. As a measure of its popularity, HTTP accounted for about 75% of Internet backbone traffic in a recent study. In spite of its success, however, HTTP1.0 is widely understood to have numerous flaws. This was the driving force behind a four year research by HTTPWG (HTTP Working Group) which lead to the development of HTTP 1.1. Instead of opening and closing a connection for each application request, HTTP 1.1 provides a persistent connection that allows multiple requests to be batched or pipelined to an output buffer. The underlying Transmission Control Protocol layer can put multiple requests (and responses to requests) into one TCP segment that gets forwarded to the Internet Protocol layer for packet transmission. Because the number of connection and disconnection requests for a sequence of "get a file" requests is reduced, fewer packets need to flow across the Internet. Since requests are pipelined, TCP segments are more efficient. The overall result is less Internet traffic and faster performance for the user. Persistent connection is similar to Netscape's HTTP 1.0 extension called Keep Alive, but provides better handling of requests that go through proxy servers.

When a browser supporting HTTP 1.1 indicates it can decompress HTML files, a server will compress them for transport across the Internet, providing a substantial aggregate savings in the amount of data that has to be transmitted. (Image files are already in a compressed format so this improvement applies only to HTML and other non-image data types.) In addition to persistent connections and other performance improvements, HTTP 1.1 also provides the ability to have multiple domain names share the same Internet address (IP address). This simplifies processing for Web servers that host a number of Web sites in what is sometimes called virtual hosting.

The HTTP/1.1 specification states the various requirements for clients, proxies, and servers. However, additional context and rationales for the changed or new features can help developers understand the motivation behind the changes, and provide them with a richer understanding of the protocol. Additionally, these rationales can give implementers a broader feel for the pros and cons of individual features. The HTTP/1.1 specification is almost three times as long as RFC1945, reflecting an increase in complexity, clarity, and specificity. Even so, numerous rules are implied by the HTTP/1.1 specification, rather than being explicitly stated. In spite of the confusion over the meaning of the ``HTTP/1.1'' protocol version token, in many cases the version number in an HTTP message can be used to deduce the capabilities of the sender. A companion document to the HTTP specification [MFGN97] clearly specified the ground rules for the use and interpretation of HTTP version numbers.

The version number in an HTTP message refers to the hop-by-hop sender of the message, not the end-to-end sender. Thus the message's version number is directly useful in determining hop-by-hop message-level capabilities, but not very useful in determining end-to-end capabilities. For example, if an HTTP/1.1 origin server receives a message forwarded by an HTTP/1.1 proxy, it cannot tell from that message whether the ultimate client uses HTTP/1.0 or HTTP/1.1.

For this reason, as well as to support debugging, HTTP/1.1 defines a Via header that describes the path followed by a forwarded message. The path information includes the HTTP version numbers of all senders along the path and is recorded by each successive recipient.

In order to ease the deployment of incompatible future protocols, HTTP/1.1 includes the new Upgrade request-header. By sending the Upgrade header, a client can inform a server of the set of protocols it supports as an alternate means of communication. The server may choose to switch protocols, but this is not mandatory.  HTTP/1.1 introduces the options method, a way for a client to learn about the capabilities of a server without actually requesting a resource. For example, a proxy can verify that the server complies with a specific version of the protocol. Unfortunately, the precise semantics of the options method were the subject of an intense and unresolved debate, and we believe that the mechanism is not yet fully specified.

HTTP/1.0 provided a simple caching mechanism. An origin server may mark a response, using the Expires header, with a time until which a cache could return the response without violating semantic transparency. Further, a cache may check the current validity of a response using what is known as a conditional request: it may include an If-Modified-Since header in a request for the resource, specifying the value given in the cached response's Last-Modified header. The server may then either respond with a 304 (Not Modified) status code, implying that the cache entry is valid, or it may send a normal 200 (OK) response to replace the cache entry.

HTTP/1.0 also included a mechanism, the Pragma: no-cache header, for the client to indicate that a request should not be satisfied from a cache.

The HTTP/1.0 caching mechanism worked moderately well, but it had many conceptual shortcomings. It did not allow either origin servers or clients to give full and explicit instructions to caches; therefore, it depended on a body of heuristics that were not well-specified. This led to two problems: incorrect caching of some responses that should not have been cached, and failure to cache some responses that could have been cached. The former causes semantic problems; the latter causes performance problems. HTTP/1.1 attempts to clarify the concepts behind caching, and to provide explicit and extensible protocol mechanisms for caching. While it retains the basic HTTP/1.0 design, it augments that design both with new features, and with more careful specifications of the existing features.

In HTTP/1.1 terminology, a cache entry is fresh until it reaches its expiration time, at which point it becomes stale. A cache need not discard a stale entry, but it normally must revalidate it with the origin server before returning it in response to a subsequent request. However, the protocol allows both origin servers and end-user clients to override this basic rule.

In HTTP/1.0, a cache revalidated an entry using the If-Modified-Since header. This header uses absolute timestamps with one-second resolution, which could lead to caching errors either because of clock synchronization errors, or because of lack of resolution. Therefore, HTTP/1.1 introduces the more general concept of an opaque cache validated string, known as an entity tag. If two responses for the same resource have the same entity tag, then they must (by specification) be identical. Because an entity tag is opaque, the origin server may use any information it deems necessary to construct it (such as a fine-grained timestamp or an internal database pointer), as long as it meets the uniqueness requirement. Clients may compare entity tags for equality, but cannot otherwise manipulate them. HTTP/1.1 servers attach entity tags to responses using the ETag header.

Network bandwidth is almost always limited. Both by intrinsically delaying the transmission of data, and through the added queuing delay caused by congestion, wasting bandwidth increases latency. HTTP/1.0 wastes bandwidth in several ways that HTTP/1.1 addresses. A typical example is a server's sending an entire (large) resource when the client only needs a small part of it. There was no way in HTTP/1.0 to request partial objects. Also, it is possible for bandwidth to be wasted in the forward direction: if a HTTP/1.0 server could not accept large requests, it would return an error code after bandwidth had already been consumed. What was missing was the ability to negotiate with a server and to ensure its ability to handle such requests before sending them. One well-known way to conserve bandwidth is through the use of data compression. While most image formats (GIF, JPEG, MPEG) are recompressed, many other data types used in the Web are not. One study showed that aggressive use of additional compression could save almost 40% of the bytes sent via HTTP . While HTTP/1.0 included some support for compression, it did not provide adequate mechanisms for negotiating the use of compression, or for distinguishing between end-to-end and hop-by-hop compression.

HTTP/1.1 makes a distinction between content-coding, which are end-to-end encodings that might be inherent in the native format of a resource, and transfer-coding, which are always hop-by-hop. Compression can be done either as a content-coding or as a transfer-coding. To support this choice, and the choice between various existing and future compression codings, without breaking compatibility with the installed base, HTTP/1.1 had to carefully revise and extend the mechanisms for negotiating the use of codings.

HTTP/1.0 includes the Content-Encoding header, which indicates the end-to-end content-coding(s) used for a message; HTTP/1.1 adds the Transfer-Encoding header, which indicates the hop-by-hop transfer-coding(s) used for a message.

HTTP/1.1 unlike HTTP/1.0 carefully specifies the Accept-Encoding header, used by a client to indicate what content-codings it can handle, and which ones it prefers. One tricky issue is the need to support ``robot'' clients that are attempting to create mirrors of the origin server's resources; another problem is the need to interoperate with HTTP/1.0 implementations, for which Accept-Encoding was poorly specified.   HTTP/1.1 resolves the problem of delimiting message bodies by introducing the Chunked transfer-coding. The sender breaks the message body into chunks of arbitrary length, and each chunk is sent with its length prepended; it marks the end of the message with a zero-length chunk. The sender uses the Transfer-Encoding: chunked header to signal the use of chunking.

This mechanism allows the sender to buffer small pieces of the message, instead of the entire message, without adding much complexity or overhead. All HTTP/1.1 implementations must be able to receive chunked messages.

The Chunked transfer-coding solves another problem, not related to performance. In HTTP/1.0, if the sender does not include a Content-Length header, the recipient cannot tell if the message has been truncated due to transmission problems. This ambiguity leads to errors, especially when truncated responses are stored in caches.