The Evolution of the Hypertext Transfer Protocol HTTP/1.1
by Jim Gettys
[Jim Gettys is a consultant engineer in Digital Equipment Corporation's
Internet Software Business Unit.
He is the Editor of the recently adopted Proposed IETF standard for
HTTP/1.1. Jim may be reached by
E-mail at jg@w3.org.
Anyone who uses the World Wide Web (WWW) uses the Hypertext Transfer
Protocol (HTTP). HTTP is an
application-level protocol for distributed, collaborative, hypermedia
information systems. It is a generic,
object-oriented protocol that can be used for many tasks, such as name
servers and distributed object
management systems, through extension of its request methods.
Features of HTTP include typing and negotiation 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. With six years of
extensive use, during which HTTP traffic has come to dominate the
Internet, serious problems and
limitations of the protocol have become obvious such that a revision of
HTTP is necessary.
HTTP/1.1's driving force is to make HTTP a good "Internet Citizen," as
some of HTTP/1.0's design flaws
cause serious operational problems on today's Internet. Problems that
were insignificant when HTTP/1.0
constituted only a tiny fraction of the traffic on the Internet have
become burning issues as HTTP traffic
has come to dominate Internet traffic. HTTP/1.1 will improve performance
for both clients and servers,
while helping reducing the load on the Internet as a whole.
HTTP/1.1 has just been approved as a Proposed Standard by the IETF, and
is an upward compatible
evolution of HTTP/1.0. HTTP/1.0, while published as an Informational
RFC, has not been a standards
track document due to highly variable implementations.
New HTTP/1.1 Features
The authors of HTTP/1.1 include Roy Fielding, University of California
Irvine; Jim Gettys (editor) and Jeff
Mogul, Digital Equipment; and H. Frystyk and Tim Berners-Lee, W3C,
acting on behalf of the IETF HTTP
working group. A quick summary of HTTP/1.1 features follow.
Persistent connections -- This allows connections between clients
and servers so they may reuse
the same connection, thus reducing connection setup latency and
TCP open and close packets
(which are not flow controlled and are believed to contribute to
the congested state of the
Internet). By avoiding TCP slow start, performance is improved,
and overhead on Web servers is
reduced.
Pipelining of connections -- This allows multiple requests and
responses to be "pipelined" over
persistent connections, again reducing both packets on the network
and increasing user-perceived
performance by reducing network round trips to fetch multiple URLs
from the same server.
New HTTP methods that include:
PUT and DELETE --for authoring an application's use
OPTIONS and UPGRADE -- to allow for graceful HTTP evolution
TRACE and "Via" header -- to ease debugging of proxy server
configuration problems
Addition of the "Host" header -- This allows Web servers to
service many web sites without using
an Internet Protocol (IP) address to distinguish the sites. The
use of many IP addresses for a single
Web server is causing many routing and address allocation
headaches for large shared web servers.
Caching --
- Protocol features to enable reliable caching in the face of
nonsynchronized clocks in proxy caches.
- Opaque cache validators to solve problems with resolution of
modification dates and easier interfacing
to database systems, where a modification date may be very difficult to
generate.
- Cache control headers enabling application developers to build
reliable applications in the face of
caching (and enabling users to enjoy better performance as a result).
HTTP/1.0 had serious problems in
this area, which often forced application developers to defeat caching
entirely to achieve reliability.
- Cache control headers so that more information may be marked as
cachable that had been presumed to
be uncachable by HTTP/1.0. Examples include searches of databases that
are updated only occasionally.
By marking the results cachable, with an expiration time set to that of
the next database update, caching
of frequent queries is possible.
These facilities should reduce the load on the network, increase
perceived performance by users, and
enable many classes of applications to take advantage of caching, thus
making the use of proxy caches
more desirable.
Warnings to clients -- Warnings will be generated if the data
clients receive may not be what the
user expected, generally due to communications or caching
failures, or during a disconnected
operation of a proxy cache.
Codification of "Accept" header -- This allows better multilingual
support for the Web in the
global environment, including the ability to return error messages
in the language of the recipient.
Range Requests (an optional part of the protocol although already
being implemented by major
Web software vendors) -- This allows clients to acquire partial
results or to continue accessing
URLs after a transfer is aborted where they left off.
Explicit requirement that HTTP software obey name service,
Time-to-Live parameters. This was
already required by the Domain Name Service Request for Comments
(RFCs), but many Web
software vendors have not been aware of the requirement. This
should improve client behavior
when there are multiple servers behind a single host name in the
Internet, as often occurs at major
web server sites. DNS lookup software is available at no cost.
This software makes TTL information
available and solves the problem in situations where operating
system libraries do not provide TTL
information to clients.
Note that many (but not all) of the features above can also be
implemented by HTTP/1.0 clients and
servers on a piecemeal basis.
An example would be range requests, already implemented in most
commercial and some
non-commercial software.
Another pressing example is the "Host" header change. Already deployed
in a majority of Web software in
use on the Internet, it needs universal deployment as quickly as
possible to solve the IP address usage
and routing problems of the large Web server operators mentioned above.
When most of the software
used with the Web supports the "Host:" header, we will be able to retire
support for IP address use, and
this should not have to wait until after HTTP/1.1 is universally
deployed. The changes required to solve
this particular problem are very small and easy to implement with
forward and backward existing
implementations of HTTP.
ment
The IETF has adopted "digest" authentication for use with HTTP to
replace "basic" authentication, which
is very insecure. There is also a draft on state management in IETF Last
Call, a codification of Netscape
"cookies" that is up for imminent adoption as a Proposed Standard.
Deferred Issues Under Consideration
Due to the urgency to finish a standard for HTTP in order to solve some
of the Internet growth problems,
a number of issues were deliberately deferred to later versions of HTTP,
and drafts of some proposals are
already out for review in the IETF HTTP working group. These include:
Hit count reporting to avoid cache busting. This is important to
increase the amount of cachable
content in the Web, as advertising and corporate support is often
required to fund Web sites. A
draft authored by Paul Leach of Microsoft and Jeff Mogul of
Digital is out for comment.
Compressed Protocol and Sticky headers proposal from Paul Leach.
PEP - HTTP protocol extensibility/negotiation. A draft from Rohit
Khare of the World Wide Web
Consortium (W3C) is in the working group for review.
Multiplexing of HTTP stream. Such multiplexing would reduce
further any need for multiple
connections; this is being prototyped to test potential benefits.
Transparent Content Negotiation. One proposal has been made to the
working Group by Koen
Holtman, Eindhoven University of Technology. Other proposals may
be made.
User agent negotiation.
Current working group plans for much of the above list are to include
these features in a future version
of HTTP version or set of RFC's to be complete by early 1997. Drafts
currently out for review may still
undergo substantial revision.
More information, including links to current and obsolete HTTP drafts
and links to Working Group
information and mailing