Changeset 624 for draft-ietf-httpbis


Ignore:
Timestamp:
26/07/09 11:56:53 (13 years ago)
Author:
fielding@…
Message:

Move overall operation above URI definitions, closer to where
it is in 2616, since it reads better that way and defines
origin server. No content changed.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r623 r624  
    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
     525   simplest case, this may be accomplished via a single connection (v)
     526   between the user agent (UA) and the origin server (O).
     527</t>
     528<figure><artwork type="drawing">
     529       request chain ------------------------&gt;
     530    UA -------------------v------------------- O
     531       &lt;----------------------- response chain
     532</artwork></figure>
     533<t>
     534   A more complicated situation occurs when one or more intermediaries
     535   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.
     547</t>
     548<figure><artwork type="drawing">
     549       request chain --------------------------------------&gt;
     550    UA -----v----- A -----v----- B -----v----- C -----v----- O
     551       &lt;------------------------------------- response chain
     552</artwork></figure>
     553<t>
     554   The figure above shows three intermediaries (A, B, and C) between the
     555   user agent and origin server. A request or response message that
     556   travels the whole chain will pass through four separate connections.
     557   This distinction is important because some HTTP communication options
     558   may apply only to the connection with the nearest, non-tunnel
     559   neighbor, only to the end-points of the chain, or to all connections
     560   along the chain. Although the diagram is linear, each participant may
     561   be engaged in multiple, simultaneous communications. For example, B
     562   may be receiving requests from many clients other than A, and/or
     563   forwarding requests to servers other than C, at the same time that it
     564   is handling A's request.
     565</t>
     566<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.
     574</t>
     575<figure><artwork type="drawing">
     576          request chain ----------&gt;
     577       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
     578          &lt;--------- response chain
     579</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
     590   of proxy caches to save transoceanic bandwidth, systems that
     591   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.
     600</t>
     601<t>
     602   HTTP communication usually takes place over TCP/IP connections. The
     603   default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does
     604   not preclude HTTP from being implemented on top of any other protocol
     605   on the Internet, or on other networks. HTTP only presumes a reliable
     606   transport; any protocol that provides such guarantees can be used;
     607   the mapping of the HTTP/1.1 request and response structures onto the
     608   transport data units of the protocol in question is outside the scope
     609   of this specification.
     610</t>
     611<t>
     612   In HTTP/1.0, most implementations used a new connection for each
     613   request/response exchange. In HTTP/1.1, a connection may be used for
     614   one or more request/response exchanges, although connections may be
     615   closed for a variety of reasons (see <xref target="persistent.connections"/>).
     616</t>
     617</section>
     618
    510619<section title="Uniform Resource Identifiers" anchor="uri">
    511620<iref primary="true" item="resource"/>
    … …  
    701810</t>
    702811</section>
    703 </section>
    704 
    705 <section title="Overall Operation" anchor="intro.overall.operation">
    706 <t>
    707    HTTP is a request/response protocol. A client sends a
    708    request to the server in the form of a request method, URI, and
    709    protocol version, followed by a MIME-like message containing request
    710    modifiers, client information, and possible body content over a
    711    connection with a server. The server responds with a status line,
    712    including the message's protocol version and a success or error code,
    713    followed by a MIME-like message containing server information, entity
    714    metadata, and possible entity-body content.
    715 </t>
    716 <t>
    717    Most HTTP communication is initiated by a user agent and consists of
    718    a request to be applied to a resource via the HTTP interface provided
    719    by some origin server. In the
    720    simplest case, this may be accomplished via a single connection (v)
    721    between the user agent (UA) and the origin server (O).
    722 </t>
    723 <figure><artwork type="drawing">
    724        request chain ------------------------&gt;
    725     UA -------------------v------------------- O
    726        &lt;----------------------- response chain
    727 </artwork></figure>
    728 <t>
    729    A more complicated situation occurs when one or more intermediaries
    730    are present in the request/response chain. There are three common
    731    forms of intermediary: proxy, gateway, and tunnel. A proxy is a
    732    forwarding agent, receiving requests for a URI in its absolute form,
    733    rewriting all or part of the message, and forwarding the reformatted
    734    request toward the server identified by the URI. A gateway is a
    735    receiving agent, acting as a layer above some other server(s) and, if
    736    necessary, translating the requests to the underlying server's
    737    protocol. A tunnel acts as a relay point between two connections
    738    without changing the messages; tunnels are used when the
    739    communication needs to pass through an intermediary (such as a
    740    firewall) even when the intermediary cannot understand the contents
    741    of the messages.
    742 </t>
    743 <figure><artwork type="drawing">
    744        request chain --------------------------------------&gt;
    745     UA -----v----- A -----v----- B -----v----- C -----v----- O
    746        &lt;------------------------------------- response chain
    747 </artwork></figure>
    748 <t>
    749    The figure above shows three intermediaries (A, B, and C) between the
    750    user agent and origin server. A request or response message that
    751    travels the whole chain will pass through four separate connections.
    752    This distinction is important because some HTTP communication options
    753    may apply only to the connection with the nearest, non-tunnel
    754    neighbor, only to the end-points of the chain, or to all connections
    755    along the chain. Although the diagram is linear, each participant may
    756    be engaged in multiple, simultaneous communications. For example, B
    757    may be receiving requests from many clients other than A, and/or
    758    forwarding requests to servers other than C, at the same time that it
    759    is handling A's request.
    760 </t>
    761 <t>
    762    Any party to the communication which is not acting as a tunnel may
    763    employ an internal cache for handling requests. The effect of a cache
    764    is that the request/response chain is shortened if one of the
    765    participants along the chain has a cached response applicable to that
    766    request. The following illustrates the resulting chain if B has a
    767    cached copy of an earlier response from O (via C) for a request which
    768    has not been cached by UA or A.
    769 </t>
    770 <figure><artwork type="drawing">
    771           request chain ----------&gt;
    772        UA -----v----- A -----v----- B - - - - - - C - - - - - - O
    773           &lt;--------- response chain
    774 </artwork></figure>
    775 <t>
    776    Not all responses are usefully cacheable, and some requests may
    777    contain modifiers which place special requirements on cache behavior.
    778    HTTP requirements for cache behavior and cacheable responses are
    779    defined in &caching;.
    780 </t>
    781 <t>
    782    In fact, there are a wide variety of architectures and configurations
    783    of caches and proxies currently being experimented with or deployed
    784    across the World Wide Web. These systems include national hierarchies
    785    of proxy caches to save transoceanic bandwidth, systems that
    786    broadcast or multicast cache entries, organizations that distribute
    787    subsets of cached data via CD-ROM, and so on. HTTP systems are used
    788    in corporate intranets over high-bandwidth links, and for access via
    789    PDAs with low-power radio links and intermittent connectivity. The
    790    goal of HTTP/1.1 is to support the wide diversity of configurations
    791    already deployed while introducing protocol constructs that meet the
    792    needs of those who build web applications that require high
    793    reliability and, failing that, at least reliable indications of
    794    failure.
    795 </t>
    796 <t>
    797    HTTP communication usually takes place over TCP/IP connections. The
    798    default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does
    799    not preclude HTTP from being implemented on top of any other protocol
    800    on the Internet, or on other networks. HTTP only presumes a reliable
    801    transport; any protocol that provides such guarantees can be used;
    802    the mapping of the HTTP/1.1 request and response structures onto the
    803    transport data units of the protocol in question is outside the scope
    804    of this specification.
    805 </t>
    806 <t>
    807    In HTTP/1.0, most implementations used a new connection for each
    808    request/response exchange. In HTTP/1.1, a connection may be used for
    809    one or more request/response exchanges, although connections may be
    810    closed for a variety of reasons (see <xref target="persistent.connections"/>).
    811 </t>
    812812</section>
    813813
Note: See TracChangeset for help on using the changeset viewer.