Ignore:
Timestamp:
Nov 14, 2008, 4:20:37 PM (11 years ago)
Author:
julian.reschke@…
Message:

move ABNF section up

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r385 r389  
    280280</section>
    281281
    282 <section title="Overall Operation" anchor="intro.overall.operation">
    283 <t>
    284    HTTP is a request/response protocol. A client sends a
    285    request to the server in the form of a request method, URI, and
    286    protocol version, followed by a MIME-like message containing request
    287    modifiers, client information, and possible body content over a
    288    connection with a server. The server responds with a status line,
    289    including the message's protocol version and a success or error code,
    290    followed by a MIME-like message containing server information, entity
    291    metainformation, and possible entity-body content. The relationship
    292    between HTTP and MIME is described in &diff2045entity;.
    293 </t>
    294 <t>
    295    Most HTTP communication is initiated by a user agent and consists of
    296    a request to be applied to a resource on some origin server. In the
    297    simplest case, this may be accomplished via a single connection (v)
    298    between the user agent (UA) and the origin server (O).
    299 </t>
    300 <figure><artwork type="drawing">
    301        request chain ------------------------&gt;
    302     UA -------------------v------------------- O
    303        &lt;----------------------- response chain
    304 </artwork></figure>
    305 <t>
    306    A more complicated situation occurs when one or more intermediaries
    307    are present in the request/response chain. There are three common
    308    forms of intermediary: proxy, gateway, and tunnel. A proxy is a
    309    forwarding agent, receiving requests for a URI in its absolute form,
    310    rewriting all or part of the message, and forwarding the reformatted
    311    request toward the server identified by the URI. A gateway is a
    312    receiving agent, acting as a layer above some other server(s) and, if
    313    necessary, translating the requests to the underlying server's
    314    protocol. A tunnel acts as a relay point between two connections
    315    without changing the messages; tunnels are used when the
    316    communication needs to pass through an intermediary (such as a
    317    firewall) even when the intermediary cannot understand the contents
    318    of the messages.
    319 </t>
    320 <figure><artwork type="drawing">
    321        request chain --------------------------------------&gt;
    322     UA -----v----- A -----v----- B -----v----- C -----v----- O
    323        &lt;------------------------------------- response chain
    324 </artwork></figure>
    325 <t>
    326    The figure above shows three intermediaries (A, B, and C) between the
    327    user agent and origin server. A request or response message that
    328    travels the whole chain will pass through four separate connections.
    329    This distinction is important because some HTTP communication options
    330    may apply only to the connection with the nearest, non-tunnel
    331    neighbor, only to the end-points of the chain, or to all connections
    332    along the chain. Although the diagram is linear, each participant may
    333    be engaged in multiple, simultaneous communications. For example, B
    334    may be receiving requests from many clients other than A, and/or
    335    forwarding requests to servers other than C, at the same time that it
    336    is handling A's request.
    337 </t>
    338 <t>
    339    Any party to the communication which is not acting as a tunnel may
    340    employ an internal cache for handling requests. The effect of a cache
    341    is that the request/response chain is shortened if one of the
    342    participants along the chain has a cached response applicable to that
    343    request. The following illustrates the resulting chain if B has a
    344    cached copy of an earlier response from O (via C) for a request which
    345    has not been cached by UA or A.
    346 </t>
    347 <figure><artwork type="drawing">
    348           request chain ----------&gt;
    349        UA -----v----- A -----v----- B - - - - - - C - - - - - - O
    350           &lt;--------- response chain
    351 </artwork></figure>
    352 <t>
    353    Not all responses are usefully cacheable, and some requests may
    354    contain modifiers which place special requirements on cache behavior.
    355    HTTP requirements for cache behavior and cacheable responses are
    356    defined in &caching;.
    357 </t>
    358 <t>
    359    In fact, there are a wide variety of architectures and configurations
    360    of caches and proxies currently being experimented with or deployed
    361    across the World Wide Web. These systems include national hierarchies
    362    of proxy caches to save transoceanic bandwidth, systems that
    363    broadcast or multicast cache entries, organizations that distribute
    364    subsets of cached data via CD-ROM, and so on. HTTP systems are used
    365    in corporate intranets over high-bandwidth links, and for access via
    366    PDAs with low-power radio links and intermittent connectivity. The
    367    goal of HTTP/1.1 is to support the wide diversity of configurations
    368    already deployed while introducing protocol constructs that meet the
    369    needs of those who build web applications that require high
    370    reliability and, failing that, at least reliable indications of
    371    failure.
    372 </t>
    373 <t>
    374    HTTP communication usually takes place over TCP/IP connections. The
    375    default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does
    376    not preclude HTTP from being implemented on top of any other protocol
    377    on the Internet, or on other networks. HTTP only presumes a reliable
    378    transport; any protocol that provides such guarantees can be used;
    379    the mapping of the HTTP/1.1 request and response structures onto the
    380    transport data units of the protocol in question is outside the scope
    381    of this specification.
    382 </t>
    383 <t>
    384    In HTTP/1.0, most implementations used a new connection for each
    385    request/response exchange. In HTTP/1.1, a connection may be used for
    386    one or more request/response exchanges, although connections may be
    387    closed for a variety of reasons (see <xref target="persistent.connections"/>).
    388 </t>
    389 </section>
    390 </section>
    391 
    392282<section title="Notational Conventions and Generic Grammar" anchor="notation">
    393283
    … …  
    600490
    601491</section>
     492
     493<section title="Overall Operation" anchor="intro.overall.operation">
     494<t>
     495   HTTP is a request/response protocol. A client sends a
     496   request to the server in the form of a request method, URI, and
     497   protocol version, followed by a MIME-like message containing request
     498   modifiers, client information, and possible body content over a
     499   connection with a server. The server responds with a status line,
     500   including the message's protocol version and a success or error code,
     501   followed by a MIME-like message containing server information, entity
     502   metainformation, and possible entity-body content. The relationship
     503   between HTTP and MIME is described in &diff2045entity;.
     504</t>
     505<t>
     506   Most HTTP communication is initiated by a user agent and consists of
     507   a request to be applied to a resource on some origin server. In the
     508   simplest case, this may be accomplished via a single connection (v)
     509   between the user agent (UA) and the origin server (O).
     510</t>
     511<figure><artwork type="drawing">
     512       request chain ------------------------&gt;
     513    UA -------------------v------------------- O
     514       &lt;----------------------- response chain
     515</artwork></figure>
     516<t>
     517   A more complicated situation occurs when one or more intermediaries
     518   are present in the request/response chain. There are three common
     519   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
     520   forwarding agent, receiving requests for a URI in its absolute form,
     521   rewriting all or part of the message, and forwarding the reformatted
     522   request toward the server identified by the URI. A gateway is a
     523   receiving agent, acting as a layer above some other server(s) and, if
     524   necessary, translating the requests to the underlying server's
     525   protocol. A tunnel acts as a relay point between two connections
     526   without changing the messages; tunnels are used when the
     527   communication needs to pass through an intermediary (such as a
     528   firewall) even when the intermediary cannot understand the contents
     529   of the messages.
     530</t>
     531<figure><artwork type="drawing">
     532       request chain --------------------------------------&gt;
     533    UA -----v----- A -----v----- B -----v----- C -----v----- O
     534       &lt;------------------------------------- response chain
     535</artwork></figure>
     536<t>
     537   The figure above shows three intermediaries (A, B, and C) between the
     538   user agent and origin server. A request or response message that
     539   travels the whole chain will pass through four separate connections.
     540   This distinction is important because some HTTP communication options
     541   may apply only to the connection with the nearest, non-tunnel
     542   neighbor, only to the end-points of the chain, or to all connections
     543   along the chain. Although the diagram is linear, each participant may
     544   be engaged in multiple, simultaneous communications. For example, B
     545   may be receiving requests from many clients other than A, and/or
     546   forwarding requests to servers other than C, at the same time that it
     547   is handling A's request.
     548</t>
     549<t>
     550   Any party to the communication which is not acting as a tunnel may
     551   employ an internal cache for handling requests. The effect of a cache
     552   is that the request/response chain is shortened if one of the
     553   participants along the chain has a cached response applicable to that
     554   request. The following illustrates the resulting chain if B has a
     555   cached copy of an earlier response from O (via C) for a request which
     556   has not been cached by UA or A.
     557</t>
     558<figure><artwork type="drawing">
     559          request chain ----------&gt;
     560       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
     561          &lt;--------- response chain
     562</artwork></figure>
     563<t>
     564   Not all responses are usefully cacheable, and some requests may
     565   contain modifiers which place special requirements on cache behavior.
     566   HTTP requirements for cache behavior and cacheable responses are
     567   defined in &caching;.
     568</t>
     569<t>
     570   In fact, there are a wide variety of architectures and configurations
     571   of caches and proxies currently being experimented with or deployed
     572   across the World Wide Web. These systems include national hierarchies
     573   of proxy caches to save transoceanic bandwidth, systems that
     574   broadcast or multicast cache entries, organizations that distribute
     575   subsets of cached data via CD-ROM, and so on. HTTP systems are used
     576   in corporate intranets over high-bandwidth links, and for access via
     577   PDAs with low-power radio links and intermittent connectivity. The
     578   goal of HTTP/1.1 is to support the wide diversity of configurations
     579   already deployed while introducing protocol constructs that meet the
     580   needs of those who build web applications that require high
     581   reliability and, failing that, at least reliable indications of
     582   failure.
     583</t>
     584<t>
     585   HTTP communication usually takes place over TCP/IP connections. The
     586   default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does
     587   not preclude HTTP from being implemented on top of any other protocol
     588   on the Internet, or on other networks. HTTP only presumes a reliable
     589   transport; any protocol that provides such guarantees can be used;
     590   the mapping of the HTTP/1.1 request and response structures onto the
     591   transport data units of the protocol in question is outside the scope
     592   of this specification.
     593</t>
     594<t>
     595   In HTTP/1.0, most implementations used a new connection for each
     596   request/response exchange. In HTTP/1.1, a connection may be used for
     597   one or more request/response exchanges, although connections may be
     598   closed for a variety of reasons (see <xref target="persistent.connections"/>).
     599</t>
     600</section>
     601</section>
     602
    602603
    603604<section title="Protocol Parameters" anchor="protocol.parameters">
Note: See TracChangeset for help on using the changeset viewer.