The Hypertext Transfer Protocol (HTTP) is an application-level 
 protocol for distributed, collaborative, hypermedia information 
 systems. HTTP has been in use by the World-Wide Web global 
 information initiative since 1990. 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 <a rel="bibref" href="rfc2616-sec17.html#bib6"="">[6]</a>, improved 
 the protocol by allowing messages to be in the format of MIME-like 
 messages, containing metainformation 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 themselves "HTTP/1.0" has necessitated a 
 protocol version change in order for two communicating applications 
 to determine each other's true capabilities. 


 This specification defines the protocol referred to as "HTTP/1.1". 
 This protocol includes more stringent requirements than HTTP/1.0 in 
 order to ensure reliable implementation of its features. 


 Practical information systems require more functionality than simple 
 retrieval, including search, front-end update, and annotation. HTTP 
 allows an open-ended set of methods and headers that indicate the 
 purpose of a request <a rel="bibref" href="rfc2616-sec17.html#bib47"="">[47]</a>. It builds on the discipline of reference 
 provided by the Uniform Resource Identifier (URI) <a rel="bibref" href="rfc2616-sec17.html#bib3"="">[3]</a>, as a location 
 (URL) <a rel="bibref" href="rfc2616-sec17.html#bib4"="">[4]</a> or name (URN) <a rel="bibref" href="rfc2616-sec17.html#bib20"="">[20]</a>, for indicating the resource to which a 


 method is to be applied. Messages are passed in a format similar to 
 that used by Internet mail [9] as defined by the Multipurpose 
 Internet Mail Extensions (MIME) <a rel="bibref" href="rfc2616-sec17.html#bib7"="">[7]</a>. 


 HTTP is also used as a generic protocol for communication between 
 user agents and proxies/gateways to other Internet systems, including 
 those supported by the SMTP <a rel="bibref" href="rfc2616-sec17.html#bib16"="">[16]</a>, NNTP <a rel="bibref" href="rfc2616-sec17.html#bib13"="">[13]</a>, FTP <a rel="bibref" href="rfc2616-sec17.html#bib18"="">[18]</a>, Gopher <a rel="bibref" href="rfc2616-sec17.html#bib2"="">[2]</a>, 
 and WAIS <a rel="bibref" href="rfc2616-sec17.html#bib10"="">[10]</a> protocols. In this way, HTTP allows basic hypermedia 
 access to resources available from diverse applications. 


 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
 document are to be interpreted as described in RFC 2119 <a rel="bibref" href="rfc2616-sec17.html#bib34"="">[34]</a>. 


 An implementation is not compliant if it fails to satisfy one or more 
 of the MUST or REQUIRED level requirements for the protocols it 
 implements. An implementation that satisfies all the MUST or REQUIRED 
 level and all the SHOULD level requirements for its protocols is said 
 to be "unconditionally compliant"; one that satisfies all the MUST 
 level requirements but not all the SHOULD level requirements for its 
 protocols is said to be "conditionally compliant." 


 This specification uses a number of terms to refer to the roles 
 played by participants in, and objects of, the HTTP communication. 


 The HTTP protocol is a request/response protocol. A client sends a 
 request to the server in the form of a request method, URI, and 
 protocol version, followed by a MIME-like message containing request 
 modifiers, client information, and possible body content over a 
 connection with a server. The server responds with a status line, 
 including the message's protocol version and a success or error code, 
 followed by a MIME-like message containing server information, entity 
 metainformation, and possible entity-body content. The relationship 
 between HTTP and MIME is described in appendix <a rel="xref" href="rfc2616-sec19.html#sec19.4"="">19.4</a>. 


 Most HTTP communication is initiated by a user agent and consists of 
 a request to be applied to a resource on some origin server. In the 
 simplest case, this may be accomplished via a single connection (v) 
 between the user agent (UA) and the origin server (O). 

request chain ------------------------> 
 UA -------------------v------------------- O 
 <;----------------------- response chain 


 A more complicated situation occurs when one or more intermediaries 
 are present in the request/response chain. There are three common 
 forms of intermediary: proxy, gateway, and tunnel. A proxy is a 
 forwarding agent, receiving requests for a URI in its absolute form, 
 rewriting all or part of the message, and forwarding the reformatted 
 request toward the server identified by the URI. A gateway is a 
 receiving agent, acting as a layer above some other server(s) and, if 
 necessary, translating the requests to the underlying server's 
 protocol. A tunnel acts as a relay point between two connections 
 without changing the messages; tunnels are used when the 
 communication needs to pass through an intermediary (such as a 
 firewall) even when the intermediary cannot understand the contents 
 of the messages. 

request chain --------------------------------------> 
 UA -----v----- A -----v----- B -----v----- C -----v----- O 
 <;------------------------------------- response chain 


 The figure above shows three intermediaries (A, B, and C) between the 
 user agent and origin server. A request or response message that 
 travels the whole chain will pass through four separate connections. 
 This distinction is important because some HTTP communication options 


 may apply only to the connection with the nearest, non-tunnel 
 neighbor, only to the end-points of the chain, or to all connections 
 along the chain. Although the diagram is linear, each participant may 
 be engaged in multiple, simultaneous communications. For example, B 
 may be receiving requests from many clients other than A, and/or 
 forwarding requests to servers other than C, at the same time that it 
 is handling A's request. 


 Any party to the communication which is not acting as a tunnel may 
 employ an internal cache for handling requests. The effect of a cache 
 is that the request/response chain is shortened if one of the 
 participants along the chain has a cached response applicable to that 
 request. The following illustrates the resulting chain if B has a 
 cached copy of an earlier response from O (via C) for a request which 
 has not been cached by UA or A. 

request chain ----------> 
 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 
 <;--------- response chain 


 Not all responses are usefully cacheable, and some requests may 
 contain modifiers which place special requirements on cache behavior. 
 HTTP requirements for cache behavior and cacheable responses are 
 defined in section 13. 


 In fact, there are a wide variety of architectures and configurations 
 of caches and proxies currently being experimented with or deployed 
 across the World Wide Web. These systems include national hierarchies 
 of proxy caches to save transoceanic bandwidth, systems that 
 broadcast or multicast cache entries, organizations that distribute 
 subsets of cached data via CD-ROM, and so on. HTTP systems are used 
 in corporate intranets over high-bandwidth links, and for access via 
 PDAs with low-power radio links and intermittent connectivity. The 
 goal of HTTP/1.1 is to support the wide diversity of configurations 
 already deployed while introducing protocol constructs that meet the 
 needs of those who build web applications that require high 
 reliability and, failing that, at least reliable indications of 
 failure. 


 HTTP communication usually takes place over TCP/IP connections. The 
 default port is TCP 80 [19], but other ports can be used. This does 
 not preclude HTTP from being implemented on top of any other protocol 
 on the Internet, or on other networks. HTTP only presumes a reliable 
 transport; any protocol that provides such guarantees can be used; 
 the mapping of the HTTP/1.1 request and response structures onto the 
 transport data units of the protocol in question is outside the scope 
 of this specification. 


 In HTTP/1.0, most implementations used a new connection for each 
 request/response exchange. In HTTP/1.1, a connection may be used for 
 one or more request/response exchanges, although connections may be 
 closed for a variety of reasons (see section <a rel="xref" href="rfc2616-sec8.html#sec8.1"="">8.1</a>).