Ignore:
Timestamp:
Jul 23, 2010, 11:35:53 PM (9 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r881 r900  
    376376      <link rel="Index" href="#rfc.index">
    377377      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    378       <link rel="Chapter" title="2 HTTP architecture" href="#rfc.section.2">
     378      <link rel="Chapter" title="2 HTTP-related architecture" href="#rfc.section.2">
    379379      <link rel="Chapter" title="3 HTTP Message" href="#rfc.section.3">
    380380      <link rel="Chapter" title="4 Request" href="#rfc.section.4">
     
    544544            </ul>
    545545         </li>
    546          <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP architecture</a><ul class="toc">
    547                <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Operation</a></li>
     546         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP-related architecture</a><ul class="toc">
     547               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li>
    548548               <li class="tocline1">2.2&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li>
    549549               <li class="tocline1">2.3&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li>
     
    863863  <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    864864  <a href="#abnf.dependencies" class="smpl">Warning</a>         = &lt;Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>&gt;
    865 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP architecture</a></h1>
     865</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP-related architecture</a></h1>
    866866      <p id="rfc.section.2.p.1">HTTP was created for the World Wide Web architecture and has evolved over time to support the scalability needs of a worldwide
    867867         hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP.
     
    870870      <div id="rfc.iref.s.1"></div>
    871871      <div id="rfc.iref.c.2"></div>
    872       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="operation" href="#operation">Client/Server Operation</a></h2>
    873       <p id="rfc.section.2.1.p.1">HTTP is a request/response protocol that operates by exchanging messages across a reliable transport or session-layer connection.
    874          An HTTP client is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests.
    875          An HTTP server is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
     872      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="operation" href="#operation">Client/Server Messaging</a></h2>
     873      <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging messages across a reliable transport or session-layer
     874         connection. An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more
     875         HTTP requests. An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
    876876      </p>
    877877      <div id="rfc.iref.u.1"></div>
    878878      <div id="rfc.iref.o.1"></div>
    879       <p id="rfc.section.2.1.p.2">Note that the terms "client" and "server" refer only to the roles that these programs perform for a particular connection.
    880          The same program may act as a client on some connections and a server on others. We use the term "user agent" to refer to
    881          the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin
    882          server" to refer to the program that can originate authoritative responses to a request.
     879      <p id="rfc.section.2.1.p.2">Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The
     880         same program may act as a client on some connections and a server on others. We use the term "user agent" to refer to the
     881         program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server"
     882         to refer to the program that can originate authoritative responses to a request.
    883883      </p>
    884884      <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
    885          the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server
    886          (O).
    887       </p>
    888       <div id="rfc.figure.u.15"></div><pre class="drawing">       request chain ------------------------&gt;
    889     UA -------------------v------------------- O
    890        &lt;----------------------- response chain
     885         the simplest case, this may be accomplished via a single bidirectional connection (===) between the user agent (UA) and the
     886         origin server (O).
     887      </p>
     888      <div id="rfc.figure.u.15"></div><pre class="drawing">         request   &gt;
     889    UA ======================================= O
     890                                &lt;   response
    891891</pre><div id="rfc.iref.m.1"></div>
    892892      <div id="rfc.iref.r.1"></div>
     
    924924         proxy, gateway, or tunnel, switching behavior based on the nature of each request.
    925925      </p>
    926       <div id="rfc.figure.u.18"></div><pre class="drawing">       request chain --------------------------------------&gt;
    927     UA -----v----- A -----v----- B -----v----- C -----v----- O
    928        &lt;------------------------------------- response chain
     926      <div id="rfc.figure.u.18"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
     927    UA =========== A =========== B =========== C =========== O
     928               &lt;             &lt;             &lt;             &lt;
    929929</pre><p id="rfc.section.2.2.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
    930930         message that travels the whole chain will pass through four separate connections. Some HTTP communication options may apply
     
    938938         in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent.
    939939      </p>
    940       <p id="rfc.section.2.2.p.5"><span id="rfc.iref.p.1"></span> A proxy is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests
    941          for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
    942          are minimal, such as for proxy requests for "http" URIs, whereas other requests may require translation to and from entirely
    943          different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
    944          for the sake of security, annotation services, or shared caching.
    945       </p>
    946       <p id="rfc.section.2.2.p.6"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A gateway (a.k.a., reverse proxy) is a receiving agent that acts as a layer above some other server(s) and translates the
    947          received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP services
    948          across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource;
    949          the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the client as
    950          if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection.
     940      <p id="rfc.section.2.2.p.5"><span id="rfc.iref.p.1"></span> A "proxy" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive
     941         requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface.
     942         Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests may require translation
     943         to and from entirely different application-layer protocols. Proxies are often used to group an organization's HTTP requests
     944         through a common intermediary for the sake of security, annotation services, or shared caching.
     945      </p>
     946      <p id="rfc.section.2.2.p.6"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
     947         the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP
     948         services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested
     949         resource; the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the
     950         client as if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection.
    951951         A gateway communicates with inbound servers using any protocol it desires, including private extensions to HTTP that are outside
    952952         the scope of this specification.
    953953      </p>
    954       <p id="rfc.section.2.2.p.7"><span id="rfc.iref.t.1"></span> A tunnel acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
     954      <p id="rfc.section.2.2.p.7"><span id="rfc.iref.t.1"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
    955955         a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. A tunnel ceases to exist
    956956         when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary,
     
    959959      <div id="rfc.iref.c.3"></div>
    960960      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
    961       <p id="rfc.section.2.3.p.1">Any party to HTTP communication that is not acting as a tunnel may employ an internal cache for handling requests. A cache
     961      <p id="rfc.section.2.3.p.1">Any party to HTTP communication that is not acting as a tunnel may employ an internal cache for handling requests. A "cache"
    962962         is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
    963963         A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
     
    968968         from O (via C) for a request which has not been cached by UA or A.
    969969      </p>
    970       <div id="rfc.figure.u.19"></div><pre class="drawing">          request chain ----------&gt;
    971        UA -----v----- A -----v----- B - - - - - - C - - - - - - O
    972           &lt;--------- response chain
    973 </pre><p id="rfc.section.2.3.p.4"><span id="rfc.iref.c.4"></span> A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
     970      <div id="rfc.figure.u.19"></div><pre class="drawing">            &gt;             &gt;
     971       UA =========== A =========== B - - - - - - C - - - - - - O
     972                  &lt;             &lt;
     973</pre><p id="rfc.section.2.3.p.4"><span id="rfc.iref.c.4"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    974974         Even when a response is cacheable, there may be additional constraints placed by the client or by the origin server on when
    975975         that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are
Note: See TracChangeset for help on using the changeset viewer.