Ignore:
Timestamp:
21/05/13 22:00:59 (7 years ago)
Author:
fielding@…
Message:

addresses #446 p1 editorial feedback

File:
1 edited

Legend:

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

    r2269 r2270  
    419419   for such reporting to only be observable in an error console or log file.
    420420   Likewise, requirements that an automated action be confirmed by the user
    421    before proceeding can be met via advance configuration choices,
    422    run-time options, or simply not proceeding with the unsafe action.
     421   before proceeding might be met via advance configuration choices,
     422   run-time options, or simple avoidance of the unsafe action; confirmation
     423   does not imply any specific user interface or interruption of normal
     424   processing if the user has already made that choice.
    423425</t>
    424426</section>
     
    449451   might be receiving requests from many clients other than A, and/or
    450452   forwarding requests to servers other than C, at the same time that it
    451    is handling A's request.
     453   is handling A's request. Likewise, later requests might be sent through a
     454   different path of connections, often based on dynamic configuration for
     455   load balancing.   
    452456</t>
    453457<t>
     
    494498<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
    495499<iref primary="true" item="accelerator"/>
    496    A "<x:dfn>gateway</x:dfn>" (a.k.a., "<x:dfn>reverse proxy</x:dfn>")
    497    is a receiving agent that acts
    498    as a layer above some other server(s) and translates the received
    499    requests to the underlying server's protocol.  Gateways are often
    500    used to encapsulate legacy or untrusted information services, to
    501    improve server performance through "<x:dfn>accelerator</x:dfn>" caching, and to
    502    enable partitioning or load-balancing of HTTP services across
    503    multiple machines.
    504 </t>
    505 <t>
    506    A gateway behaves as an origin server on its outbound connection and
    507    as a user agent on its inbound connection.
     500   A "<x:dfn>gateway</x:dfn>" (a.k.a., "<x:dfn>reverse proxy</x:dfn>") is an
     501   intermediary that acts as an origin server for the outbound connection, but
     502   translates received requests and forwards them inbound to another server or
     503   servers. Gateways are often used to encapsulate legacy or untrusted
     504   information services, to improve server performance through
     505   "<x:dfn>accelerator</x:dfn>" caching, and to enable partitioning or load
     506   balancing of HTTP services across multiple machines.
     507</t>
     508<t>
    508509   All HTTP requirements applicable to an origin server
    509510   also apply to the outbound communication of a gateway.
     
    515516   connection and &MUST; implement the <x:ref>Connection</x:ref>
    516517   (<xref target="header.connection"/>) and <x:ref>Via</x:ref>
    517    (<xref target="header.via"/>) header fields for both connections.
     518   (<xref target="header.via"/>) header fields for both inbound and outbound
     519   connections.
    518520</t>
    519521<t><iref primary="true" item="tunnel"/>
     
    21252127</artwork></figure>
    21262128<t>
    2127    The presence of the keyword "trailers" indicates that the client is
    2128    willing to accept trailer fields in a chunked transfer coding,
    2129    as defined in <xref target="chunked.encoding"/>, on behalf of itself and
    2130    any downstream clients. For chained requests, this implies that either:
     2129   The presence of the keyword "trailers" indicates that the client is willing
     2130   to accept trailer fields in a chunked transfer coding, as defined in
     2131   <xref target="chunked.encoding"/>, on behalf of itself and any downstream
     2132   clients. For requests from an intermediary, this implies that either:
    21312133   (a) all downstream clients are willing to accept trailer fields in the
    21322134   forwarded response; or,
    2133    (b) the client will attempt to buffer the response on behalf of downstream
    2134    recipients.
     2135   (b) the intermediary will attempt to buffer the response on behalf of
     2136   downstream recipients.
    21352137   Note that HTTP/1.1 does not define any means to limit the size of a
    2136    chunked response such that a client can be assured of buffering the
     2138   chunked response such that an intermediary can be assured of buffering the
    21372139   entire response.
    21382140</t>
     
    22002202</t>
    22012203<t>
    2202    If the client has a response cache and the request semantics can be
    2203    satisfied by a cache (<xref target="Part6"/>), then the request is
    2204    usually directed to the cache first.
     2204   If the client has a cache <xref target="Part6"/> and the request can be
     2205   satisfied by it, then the request is
     2206   usually directed there first.
    22052207</t>
    22062208<t>
     
    26702672</t>
    26712673<t>
    2672    A non-transforming proxy &MUST; preserve the message payload (&payload;).
    2673    A transforming proxy &MUST; preserve the payload of a message that
     2674   A non-transforming proxy &MUST-NOT; modify the message payload (&payload;).
     2675   A transforming proxy &MUST-NOT; modify the payload of a message that
    26742676   contains the no-transform cache-control directive.
    26752677</t>
     
    31013103  <x:ref>protocol-version</x:ref> = <x:ref>token</x:ref>
    31023104</artwork></figure>
    3103 <t>
    3104    For example,
    3105 </t>
    3106 <figure><artwork type="example">
    3107   Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     3105<figure><preamble>
     3106   The following is a hypothetical example sent by a client:
     3107</preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     3108GET /hello.txt HTTP/1.1
     3109Host: www.example.com
     3110Connection: upgrade
     3111Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     3112
    31083113</artwork></figure>
    31093114<t>
     
    31343139   protocol; an OPTIONS request can be honored by any protocol.
    31353140</t>
     3141<figure><preamble>
     3142   The following is an example response to the above hypothetical request:
     3143</preamble><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
     3144HTTP/1.1 101 Switching Protocols
     3145Connection: upgrade
     3146Upgrade: HTTP/2.0
     3147
     3148[... data stream switches to HTTP/2.0 with an appropriate response
     3149(as defined by new protocol) to the "GET /hello.txt" request ...]
     3150</artwork></figure>
    31363151<t>
    31373152   When Upgrade is sent, a sender &MUST; also send a
     
    36313646   This specification also provides a way for servers to reject messages that
    36323647   have request-targets that are too long (&status-414;) or request entities
    3633    that are too large (&status-4xx;).
     3648   that are too large (&status-4xx;). Additional status codes related to
     3649   capacity limits have been defined by extensions to HTTP
     3650   <xref target="RFC6585"/>.
    36343651</t>
    36353652<t>
     
    46394656</reference>
    46404657
     4658<reference anchor='RFC6585'>
     4659  <front>
     4660    <title>Additional HTTP Status Codes</title>
     4661    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
     4662      <organization>Rackspace</organization>
     4663    </author>
     4664    <author initials='R.' surname='Fielding' fullname='R. Fielding'>
     4665      <organization>Adobe</organization>
     4666    </author>
     4667    <date year='2012' month='April' />
     4668   </front>
     4669   <seriesInfo name='RFC' value='6585' />
     4670</reference>
     4671
    46414672<!--<reference anchor='BCP97'>
    46424673  <front>
Note: See TracChangeset for help on using the changeset viewer.