Ignore:
Timestamp:
27/07/09 16:05:58 (13 years ago)
Author:
fielding@…
Message:

Split the section on overall operation into sections for
client/server operation, intermediaries, caches, and transport independence.
Move most of the terminology section into these sections so that terms
are learned as they are introduced (in context).

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r627 r630  
    508508</t>
    509509
    510 <section title="Overall Operation" anchor="intro.overall.operation">
    511 <t>
    512    HTTP is a request/response protocol. A client sends a
    513    request to the server in the form of a request method, URI, and
    514    protocol version, followed by a MIME-like message containing request
    515    modifiers, client information, and possible body content over a
    516    connection with a server. The server responds with a status line,
    517    including the message's protocol version and a success or error code,
    518    followed by a MIME-like message containing server information, entity
    519    metadata, and possible entity-body content.
    520 </t>
    521 <t>
    522    Most HTTP communication is initiated by a user agent and consists of
    523    a request to be applied to a resource via the HTTP interface provided
    524    by some origin server. In the
     510<section title="Client/Server Operation" anchor="operation">
     511<iref item="client"/>
     512<iref item="server"/>
     513<iref item="connection"/>
     514<t>
     515   HTTP is a request/response protocol that operates by exchanging messages
     516   across a reliable transport or session-layer connection. An HTTP client
     517   is a program that establishes a connection to a server for the purpose
     518   of sending one or more HTTP requests.  An HTTP server is a program that
     519   accepts connections in order to service HTTP requests by sending HTTP
     520   responses.
     521</t>
     522<iref item="user agent"/>
     523<iref item="origin server"/>
     524<t>
     525   Note that the terms "client" and "server" refer only to the roles that
     526   these programs perform for a particular connection.  The same program
     527   may act as a client on some connections and a server on others.  We use
     528   the term "user agent" to refer to the program that initiates a request,
     529   such as a WWW browser, editor, or spider (web-traversing robot), and
     530   the term "origin server" to refer to the program that can originate
     531   authoritative responses to a request.
     532</t>
     533<t>
     534   Most HTTP communication consists of a retrieval request (GET) for
     535   a representation of some resource identified by a URI.  In the
    525536   simplest case, this may be accomplished via a single connection (v)
    526537   between the user agent (UA) and the origin server (O).
    … …  
    531542       &lt;----------------------- response chain
    532543</artwork></figure>
     544<iref item="message"/>
     545<iref item="request"/>
     546<iref item="response"/>
     547<t>
     548   A client sends an HTTP request to the server in the form of a request
     549   message (<xref target="request"/>), beginning with a method, URI, and
     550   protocol version, followed by MIME-like header fields containing
     551   request modifiers, client information, and payload metadata, an empty
     552   line, and finally the payload body (if any).
     553   The server response (<xref target="response"/>) begins with a status line,
     554   including the protocol version, a success or error code, and textual
     555   reason phrase, followed by MIME-like header fields containing server
     556   information, resource metadata, payload metadata, an empty line, and
     557   finally the payload body (if any).
     558</t>
     559<figure><preamble>
     560   The following example illustrates a typical message exchange for a
     561   GET request on the URI "http://www.example.com/hello.txt":
     562</preamble><artwork type="drawing">
     563client request:
     564
     565  GET /hello.txt HTTP/1.1
     566  User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
     567  Host: www.example.com
     568  Accept: */*
     569
     570server response:
     571
     572  HTTP/1.1 200 OK
     573  Date: Mon, 27 Jul 2009 12:28:53 GMT
     574  Server: Apache
     575  Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
     576  ETag: "34aa387-d-1568eb00"
     577  Accept-Ranges: bytes
     578  Content-Length: 13
     579  Vary: Accept-Encoding
     580  Content-Type: text/plain
     581 
     582  Hello World!
     583</artwork></figure>
     584</section>
     585
     586<section title="Intermediaries" anchor="intermediaries">
    533587<t>
    534588   A more complicated situation occurs when one or more intermediaries
    535589   are present in the request/response chain. There are three common
    536    forms of intermediary: proxy, gateway, and tunnel. A proxy is a
    537    forwarding agent, receiving requests for a URI in its absolute form,
    538    rewriting all or part of the message, and forwarding the reformatted
    539    request toward the server identified by the URI. A gateway is a
    540    receiving agent, acting as a layer above some other server(s) and, if
    541    necessary, translating the requests to the underlying server's
    542    protocol. A tunnel acts as a relay point between two connections
    543    without changing the messages; tunnels are used when the
    544    communication needs to pass through an intermediary (such as a
    545    firewall) even when the intermediary cannot understand the contents
    546    of the messages.
     590   forms of intermediary: proxy, gateway, and tunnel.  In some cases,
     591   a single intermediary may act as an origin server, proxy, gateway,
     592   or tunnel, switching behavior based on the nature of each request.
    547593</t>
    548594<figure><artwork type="drawing">
    … …  
    555601   user agent and origin server. A request or response message that
    556602   travels the whole chain will pass through four separate connections.
    557    This distinction is important because some HTTP communication options
     603   Some HTTP communication options
    558604   may apply only to the connection with the nearest, non-tunnel
    559605   neighbor, only to the end-points of the chain, or to all connections
    … …  
    565611</t>
    566612<t>
    567    Any party to the communication which is not acting as a tunnel may
    568    employ an internal cache for handling requests. The effect of a cache
    569    is that the request/response chain is shortened if one of the
    570    participants along the chain has a cached response applicable to that
    571    request. The following illustrates the resulting chain if B has a
    572    cached copy of an earlier response from O (via C) for a request which
    573    has not been cached by UA or A.
     613<iref item="upstream"/><iref item="downstream"/>
     614<iref item="inbound"/><iref item="outbound"/>
     615   We use the terms "upstream" and "downstream" to describe various
     616   requirements in relation to the directional flow of a message:
     617   all messages flow from upstream to downstream.
     618   Likewise, we use the terms "inbound" and "outbound" to refer to
     619   directions in relation to the request path: "inbound" means toward
     620   the origin server and "outbound" means toward the user agent.
     621</t>
     622<t><iref item="proxy"/>
     623   A proxy is a message forwarding agent that is selected by the
     624   client, usually via local configuration rules, to receive requests
     625   for some type(s) of absolute URI and attempt to satisfy those
     626   requests via translation through the HTTP interface.  Some translations
     627   are minimal, such as for proxy requests for "http" URIs, whereas
     628   other requests may require translation to and from entirely different
     629   application-layer protocols. Proxies are often used to group an
     630   organization's HTTP requests through a common intermediary for the
     631   sake of security, annotation services, or shared caching.
     632</t>
     633<t><iref item="gateway"/><iref item="reverse proxy"/>
     634   A gateway (a.k.a., reverse proxy) is a receiving agent that acts
     635   as a layer above some other server(s) and translates the received
     636   requests to the underlying server's protocol.  Gateways are often
     637   used for load balancing or partitioning HTTP services across
     638   multiple machines.
     639   Unlike a proxy, a gateway receives requests as if it were the
     640   origin server for the requested resource; the requesting client
     641   will not be aware that it is communicating with a gateway.
     642   A gateway communicates with the client as if the gateway is the
     643   origin server and thus is subject to all of the requirements on
     644   origin servers for that connection.  A gateway communicates
     645   with inbound servers using any protocol it desires, including
     646   private extensions to HTTP that are outside the scope of this
     647   specification.
     648</t>
     649<t><iref item="tunnel"/>
     650   A tunnel acts as a blind relay between two connections
     651   without changing the messages. Once active, a tunnel is not
     652   considered a party to the HTTP communication, though the tunnel may
     653   have been initiated by an HTTP request. A tunnel ceases to exist when
     654   both ends of the relayed connection are closed. Tunnels are used to
     655   extend a virtual connection through an intermediary, such as when
     656   transport-layer security is used to establish private communication
     657   through a shared firewall proxy.
     658</t>
     659</section>
     660
     661<section title="Caches" anchor="caches">
     662<iref item="cache"/>
     663<t>
     664   Any party to HTTP communication that is not acting as a tunnel may
     665   employ an internal cache for handling requests.
     666   A cache is a local store of previous response messages and the
     667   subsystem that controls its message storage, retrieval, and deletion.
     668   A cache stores cacheable responses in order to reduce the response
     669   time and network bandwidth consumption on future, equivalent
     670   requests. Any client or server may include a cache, though a cache
     671   cannot be used by a server while it is acting as a tunnel.
     672</t>
     673<t>
     674   The effect of a cache is that the request/response chain is shortened
     675   if one of the participants along the chain has a cached response
     676   applicable to that request. The following illustrates the resulting
     677   chain if B has a cached copy of an earlier response from O (via C)
     678   for a request which has not been cached by UA or A.
    574679</t>
    575680<figure><artwork type="drawing">
    … …  
    578683          &lt;--------- response chain
    579684</artwork></figure>
    580 <t>
    581    Not all responses are usefully cacheable, and some requests may
    582    contain modifiers which place special requirements on cache behavior.
    583    HTTP requirements for cache behavior and cacheable responses are
    584    defined in &caching;.
    585 </t>
    586 <t>
    587    In fact, there are a wide variety of architectures and configurations
    588    of caches and proxies currently being experimented with or deployed
    589    across the World Wide Web. These systems include national hierarchies
     685<t><iref item="cacheable"/>
     686   A response is cacheable if a cache is allowed to store a copy of
     687   the response message for use in answering subsequent requests.
     688   Even when a response is cacheable, there may be additional
     689   constraints placed by the client or by the origin server on when
     690   that cached response can be used for a particular request. HTTP
     691   requirements for cache behavior and cacheable responses are
     692   defined in &caching;. 
     693</t>
     694<t>
     695   There are a wide variety of architectures and configurations
     696   of caches and proxies deployed across the World Wide Web and
     697   inside large organizations. These systems include national hierarchies
    590698   of proxy caches to save transoceanic bandwidth, systems that
    591699   broadcast or multicast cache entries, organizations that distribute
    592    subsets of cached data via CD-ROM, and so on. HTTP systems are used
    593    in corporate intranets over high-bandwidth links, and for access via
    594    PDAs with low-power radio links and intermittent connectivity. The
    595    goal of HTTP/1.1 is to support the wide diversity of configurations
    596    already deployed while introducing protocol constructs that meet the
    597    needs of those who build web applications that require high
    598    reliability and, failing that, at least reliable indications of
    599    failure.
     700   subsets of cached data via CD-ROM, and so on.
     701</t>
     702</section>
     703
     704<section title="Transport Independence" anchor="transport-independence">
     705<t>
     706  HTTP systems are used in a wide variety of environments, from
     707  corporate intranets with high-bandwidth links to long-distance
     708  communication over low-power radio links and intermittent connectivity.
    600709</t>
    601710<t>
    … …  
    42034312</t>
    42044313<t>
    4205   <iref item="cache"/>
    4206   <x:dfn>cache</x:dfn>
    4207   <list>
    4208     <t>
    4209       A program's local store of response messages and the subsystem
    4210       that controls its message storage, retrieval, and deletion. A
    4211       cache stores cacheable responses in order to reduce the response
    4212       time and network bandwidth consumption on future, equivalent
    4213       requests. Any client or server may include a cache, though a cache
    4214       cannot be used by a server that is acting as a tunnel.
    4215     </t>
    4216   </list>
    4217 </t>
    4218 <t>
    4219   <iref item="cacheable"/>
    4220   <x:dfn>cacheable</x:dfn>
    4221   <list>
    4222     <t>
    4223       A response is cacheable if a cache is allowed to store a copy of
    4224       the response message for use in answering subsequent requests. The
    4225       rules for determining the cacheability of HTTP responses are
    4226       defined in &caching;. Even if a resource is cacheable, there may
    4227       be additional constraints on whether a cache can use the cached
    4228       copy for a particular request.
    4229     </t>
    4230   </list>
    4231 </t>
    4232 <t>
    4233   <iref item="client"/>
    4234   <x:dfn>client</x:dfn>
    4235   <list>
    4236     <t>
    4237       A program that establishes connections for the purpose of sending
    4238       requests.
    4239     </t>
    4240   </list>
    4241 </t>
    4242 <t>
    4243   <iref item="connection"/>
    4244   <x:dfn>connection</x:dfn>
    4245   <list>
    4246     <t>
    4247       A transport layer virtual circuit established between two programs
    4248       for the purpose of communication.
    4249     </t>
    4250   </list>
    4251 </t>
    4252 <t>
    42534314  <iref item="content negotiation"/>
    42544315  <x:dfn>content negotiation</x:dfn>
    … …  
    42754336</t>
    42764337<t>
    4277   <iref item="gateway"/>
    4278   <x:dfn>gateway</x:dfn>
    4279   <list>
    4280     <t>
    4281       A server which acts as an intermediary for some other server.
    4282       Unlike a proxy, a gateway receives requests as if it were the
    4283       origin server for the requested resource; the requesting client
    4284       may not be aware that it is communicating with a gateway.
    4285     </t>
    4286   </list>
    4287 </t>
    4288 <t>
    4289   <iref item="inbound"/>
    4290   <iref item="outbound"/>
    4291   <x:dfn>inbound</x:dfn>/<x:dfn>outbound</x:dfn>
    4292   <list>
    4293     <t>
    4294       Inbound and outbound refer to the request and response paths for
    4295       messages: "inbound" means "traveling toward the origin server",
    4296       and "outbound" means "traveling toward the user agent"
    4297     </t>
    4298   </list>
    4299 </t>
    4300 <t>
    4301   <iref item="message"/>
    4302   <x:dfn>message</x:dfn>
    4303   <list>
    4304     <t>
    4305       The basic unit of HTTP communication, consisting of a structured
    4306       sequence of octets matching the syntax defined in <xref target="http.message"/> and
    4307       transmitted via the connection.
    4308     </t>
    4309   </list>
    4310 </t>
    4311 <t>
    4312   <iref item="origin server"/>
    4313   <x:dfn>origin server</x:dfn>
    4314   <list>
    4315     <t>
    4316       The server on which a given resource resides or is to be created.
    4317     </t>
    4318   </list>
    4319 </t>
    4320 <t>
    4321   <iref item="proxy"/>
    4322   <x:dfn>proxy</x:dfn>
    4323   <list>
    4324     <t>
    4325       An intermediary program which acts as both a server and a client
    4326       for the purpose of making requests on behalf of other clients.
    4327       Requests are serviced internally or by passing them on, with
    4328       possible translation, to other servers. A proxy &MUST; implement
    4329       both the client and server requirements of this specification. A
    4330       "transparent proxy" is a proxy that does not modify the request or
    4331       response beyond what is required for proxy authentication and
    4332       identification. A "non-transparent proxy" is a proxy that modifies
    4333       the request or response in order to provide some added service to
    4334       the user agent, such as group annotation services, media type
    4335       transformation, protocol reduction, or anonymity filtering. Except
    4336       where either transparent or non-transparent behavior is explicitly
    4337       stated, the HTTP proxy requirements apply to both types of
    4338       proxies.
    4339     </t>
    4340   </list>
    4341 </t>
    4342 <t>
    4343   <iref item="request"/>
    4344   <x:dfn>request</x:dfn>
    4345   <list>
    4346     <t>
    4347       An HTTP request message, as defined in <xref target="request"/>.
    4348     </t>
    4349   </list>
    4350 </t>
    4351 <t>
    4352   <iref item="response"/>
    4353   <x:dfn>response</x:dfn>
    4354   <list>
    4355     <t>
    4356       An HTTP response message, as defined in <xref target="response"/>.
    4357     </t>
    4358   </list>
    4359 </t>
    4360 <t>
    43614338  <iref item="representation"/>
    43624339  <x:dfn>representation</x:dfn>
    … …  
    43664343      negotiation, as described in &content.negotiation;. There may exist multiple
    43674344      representations associated with a particular response status.
    4368     </t>
    4369   </list>
    4370 </t>
    4371 <t>
    4372   <iref item="server"/>
    4373   <x:dfn>server</x:dfn>
    4374   <list>
    4375     <t>
    4376       An application program that accepts connections in order to
    4377       service requests by sending back responses. Any given program may
    4378       be capable of being both a client and a server; our use of these
    4379       terms refers only to the role being performed by the program for a
    4380       particular connection, rather than to the program's capabilities
    4381       in general. Likewise, any server may act as an origin server,
    4382       proxy, gateway, or tunnel, switching behavior based on the nature
    4383       of each request.
    4384     </t>
    4385   </list>
    4386 </t>
    4387 <t>
    4388   <iref item="tunnel"/>
    4389   <x:dfn>tunnel</x:dfn>
    4390   <list>
    4391     <t>
    4392       An intermediary program which is acting as a blind relay between
    4393       two connections. Once active, a tunnel is not considered a party
    4394       to the HTTP communication, though the tunnel may have been
    4395       initiated by an HTTP request. The tunnel ceases to exist when both
    4396       ends of the relayed connections are closed.
    4397     </t>
    4398   </list>
    4399 </t>
    4400 <t>
    4401   <iref item="upstream"/>
    4402   <iref item="downstream"/>
    4403   <x:dfn>upstream</x:dfn>/<x:dfn>downstream</x:dfn>
    4404   <list>
    4405     <t>
    4406       Upstream and downstream describe the flow of a message: all
    4407       messages flow from upstream to downstream.
    4408     </t>
    4409   </list>
    4410 </t>
    4411 <t>
    4412   <iref item="user agent"/>
    4413   <x:dfn>user agent</x:dfn>
    4414   <list>
    4415     <t>
    4416       The client which initiates a request. These are often browsers,
    4417       editors, spiders (web-traversing robots), or other end user tools.
    44184345    </t>
    44194346  </list>
Note: See TracChangeset for help on using the changeset viewer.