Key differences between HTTP 1.0 and HTTP - ETH Z

1 ELSEVIERKey differences between http = and http = Krishnamurthya, , Jeffrey C. Mogulb, David M. KristolcaAT&T Labs-Research, 180 Park Avenue, Florham Park, NJ 07932, USAbWestern Research Lab, Compaq Computer Corp., 250 University Avenue, Palo Alto, CA 94301, USAcBell Laboratories, 600 Mountain Avenue, Murray Hill, NJ 07974, USAA bstractThe http = protocol is the result of four years of discussion and debate among a broad group of Web researchersand developers. It improves upon its phenomenally successful predecessor, http = , in numerous ways. We discuss thedifferences between http = and http = , as well as some of the rationale behind these changes. 1999 Publishedby Elsevier Science All rights : http = ; http = IntroductionBy any reasonable standard, the http = pro-tocol has been stunningly successful. As a measureof its popularity, http accounted for about 75% ofInternet backbone traffic in a recent study [35].

2 Inspite of its success, however, http = is widelyunderstood to have numerous evolved from the original versionof http (which is still in rare use). The processleading to http = involved significant debate andexperimentation, but never produced a formal spec-ification. The http Working Group ( http -WG)of the Internet Engineering Task Force (IETF) pro-duced a document (RFC1945) [2] that described the common usage of http = , but did not attemptto create a formal standard out of the many variantimplementations. Instead, over a period of roughlyfour years, the http -WG developed an improvedprotocol, known as http = The http = spec- Corresponding author. E-mail: [9] is soon to become an IETF Draft Stan-dard. Recent versions of some popular agents (MSIE,Apache) claim http = compliance in their re-quests or responses, and many implementations havebeen tested for interoperable compliance with thespecification [24,30].

3 The http = specification states the vari-ous requirements for clients, proxies, and , additional context and rationales for thechanged or new features can help developers under-stand the motivation behind the changes, and providethem with a richer understanding of the , these rationales can give implementorsa broader feel for the pros and cons of this paper we describe the major changes be-tween the http = and http = protocols. TheHTTP= specification is almost three times as longas RFC1945, reflecting an increase in complexity,clarity, and specificity. Even so, numerous rules areimplied by the http = specification, rather thanbeing explicitly stated. While some attempts have 1999 Published by Elsevier Science All rights made to document the differences betweenHTTP= and http = ([23,36], section of[9]) we know of no published analysis that coversmajor differences and the rationale behind them, andthat reflects the most recent (and probably near-final)revision of the http = specification.

4 Because theHTTP-WG, a large and international group of re-searchers and developers, conducted most of its dis-cussions via its mailing list, the archive of that list [5]documents the history of the http = effort. Butthat archive contains over 8500 messages, renderingit opaque to all but the most determined structure our discussion by (somewhat arbi-trarily) dividing the protocol changes into nine majorareas:(1) Extensibility(2) Caching(3) Bandwidth optimization(4) Network connection management(5) Message transmission(6) Internet address conservation(7) Error notification(8) Security, integrity, and authentication(9) Content negotiationWe devote a section to each area, including themotivation for changes and a description of thecorresponding new ExtensibilityThe http = effort assumed, from the outset,that compatibility with the installed base of http implementations (including many that did not con-form with [2]) was mandatory.

5 It seemed unlikelythat most software vendors or Web site operatorswould deploy systems that failed to interoperate withthe millions of existing clients, servers, and the http = effort took over fouryears, and generated numerous interim draft doc-uments, many implementors deployed systems usingthe http = protocol version before the finalversion of the specification was finished. This cre-ated another compatibility problem: the final ver-sion had to be substantially compatible with thesepseudo- http = versions, even if the interim draftsturned out to have errors in absolute requirements for compatibilitywith poorly specified prior versions led to a numberof idiosyncrasies and non-uniformities in the finaldesign. It is not possible to understand the rationalefor all of the http = features without recognizingthis compatibility issue also underlined the needto include, in http = , as much support as possiblefor future extensibility.

6 That is, if a future versionof http were to be designed, it should not behamstrung by any additional compatibility that http has always specified that if animplementation receives a header that it does notunderstand, it must ignore the header. This ruleallows a multitude of extensions without any changeto the protocol version, although it does not by itselfsupport all possible Version numbersIn spite of the confusion over the meaning of the http = protocol version token (does it implycompatibility with one of the interim drafts, or withthe final standard?), in many cases the version num-ber in an http message can be used to deduce thecapabilities of the sender. A companion documentto the http specification [26] clearly specified theground rules for the use and interpretation of http version version number in an http message refersto the hop-by-hop sender of the message, not theend-to-end sender.

7 Thus the message s version num-ber is directly useful in determining hop-by-hopmessage-level capabilities, but not very useful indetermining end-to-end capabilities. For example,if an http = origin server receives a messageforwarded by an http = proxy, it cannot tellfrom that message whether the ultimate client usesHTTP= or http = this reason, as well as to support debugging, http = defines aViaheader that describes thepath followed by a forwarded message. The pathinformation includes the http version numbers ofall senders along the path and is recorded by eachsuccessive recipient. (Only the last of multiple con-secutive http = senders will be listed, becauseHTTP= proxies will not add information to theViaheader.) The OPTIONS methodHTTP= introduces theOPTIONS method, away for a client to learn about the capabilities ofa server without actually requesting a resource.

8 Forexample, a proxy can verify that the server complieswith a specific version of the protocol. Unfortunately,the precise semantics of theOPTIONS method werethe subject of an intense and unresolved debate,and we believe that the mechanism is not yet Upgrading to other protocolsIn order to ease the deployment of incompat-ible future protocols, http = includes the newUpgraderequest-header. By sending theUpgradeheader, a client can inform a server of the set of pro-tocols it supports as an alternate means of commu-nication. The server may choose to switch protocols,but this is not CachingWeb developers recognized early on that thecaching of responses was both possible and highlydesirable. Caching is effective because a few re-sources are requested often by many users, or repeat-edly by a given user.

9 Caches are employed in mostWeb browsers and in many proxy servers; occa-sionally they are also employed in conjunction withcertain origin servers. Web caching products, suchas Cisco s cache engine [4] and Inktomi s TrafficServer [18] (to name two), are now a major researchers have studied the effectivenessof http caching [20,6,1,17]. Caching improvesuser-perceived latency by eliminating the networkcommunication with the origin server. Caching alsoreduces bandwidth consumption, by avoiding thetransmission of unnecessary network packets. Re-duced bandwidth consumption also indirectly re-duces latency for uncached interactions, by reducingnetwork congestion. Finally, caching can reduce theload on origin servers (and on intermediate proxies),further improving latency for uncached risk with caching is that the caching mech-anism might not be semantically transparent : thatis, it might return a response different from whatwould be returned by direct communication with theorigin server.

10 While some applications can toleratenon-transparent responses, many Web applications(electronic commerce, for example) Caching in http = provided a simple caching origin server may mark a response, using theExpiresheader, with a time until which a cachecould return the response without violating seman-tic transparency. Further, a cache may check the cur-rent validity of a response using what is known asa conditional request: it may include anIf-Modi-fied-Sinceheader in a request for the resource,specifying the value given in the cached response sLast-Modifiedheader. The server may then eitherrespond with a 304 (Not Modified) status code, im-plying that the cache entry is valid, or it may send anormal 200 (OK) response to replace the cache also included a mechanism, thePragma: no-cacheheader, for the client to indicatethat a request should not be satisfied from a http = caching mechanism worked mod-erately well, but it had many conceptual shortcom-ings.