Changeset 2270 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

21/05/13 22:00:59 (10 years ago)

Author:

fielding@…

Message:

addresses #446 p1 editorial feedback

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (11 diffs)

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

@@ -419 +419 @@
    for such reporting to only be observable in an error console or log file.
    Likewise, requirements that an automated action be confirmed by the user
-   before proceeding can be met via advance configuration choices,
-   run-time options, or simply not proceeding with the unsafe action.
+   before proceeding might be met via advance configuration choices,
+   run-time options, or simple avoidance of the unsafe action; confirmation
+   does not imply any specific user interface or interruption of normal
+   processing if the user has already made that choice.
 </t>
 </section>
@@ -449 +451 @@
    might be receiving requests from many clients other than A, and/or
    forwarding requests to servers other than C, at the same time that it
-   is handling A's request.
+   is handling A's request. Likewise, later requests might be sent through a
+   different path of connections, often based on dynamic configuration for
+   load balancing.   
 </t>
 <t>
@@ -494 +498 @@
 <t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
 <iref primary="true" item="accelerator"/>
-   A "<x:dfn>gateway</x:dfn>" (a.k.a., "<x:dfn>reverse proxy</x:dfn>")
-   is a receiving agent that acts
-   as a layer above some other server(s) and translates the received
-   requests to the underlying server's protocol.  Gateways are often
-   used to encapsulate legacy or untrusted information services, to
-   improve server performance through "<x:dfn>accelerator</x:dfn>" caching, and to
-   enable partitioning or load-balancing of HTTP services across
-   multiple machines.
-</t>
-<t>
-   A gateway behaves as an origin server on its outbound connection and
-   as a user agent on its inbound connection.
+   A "<x:dfn>gateway</x:dfn>" (a.k.a., "<x:dfn>reverse proxy</x:dfn>") is an
+   intermediary that acts as an origin server for the outbound connection, but
+   translates received requests and forwards them inbound to another server or
+   servers. Gateways are often used to encapsulate legacy or untrusted
+   information services, to improve server performance through
+   "<x:dfn>accelerator</x:dfn>" caching, and to enable partitioning or load
+   balancing of HTTP services across multiple machines.
+</t>
+<t>
    All HTTP requirements applicable to an origin server
    also apply to the outbound communication of a gateway.
@@ -515 +516 @@
    connection and &MUST; implement the <x:ref>Connection</x:ref>
    (<xref target="header.connection"/>) and <x:ref>Via</x:ref>
-   (<xref target="header.via"/>) header fields for both connections.
+   (<xref target="header.via"/>) header fields for both inbound and outbound
+   connections.
 </t>
 <t><iref primary="true" item="tunnel"/>
@@ -2125 +2127 @@
 </artwork></figure>
 <t>
-   The presence of the keyword "trailers" indicates that the client is
-   willing to accept trailer fields in a chunked transfer coding,
-   as defined in <xref target="chunked.encoding"/>, on behalf of itself and
-   any downstream clients. For chained requests, this implies that either:
+   The presence of the keyword "trailers" indicates that the client is willing
+   to accept trailer fields in a chunked transfer coding, as defined in
+   <xref target="chunked.encoding"/>, on behalf of itself and any downstream
+   clients. For requests from an intermediary, this implies that either:
    (a) all downstream clients are willing to accept trailer fields in the
    forwarded response; or,
-   (b) the client will attempt to buffer the response on behalf of downstream
-   recipients.
+   (b) the intermediary will attempt to buffer the response on behalf of
+   downstream recipients.
    Note that HTTP/1.1 does not define any means to limit the size of a
-   chunked response such that a client can be assured of buffering the
+   chunked response such that an intermediary can be assured of buffering the
    entire response.
 </t>
@@ -2200 +2202 @@
 </t>
 <t>
-   If the client has a response cache and the request semantics can be
-   satisfied by a cache (<xref target="Part6"/>), then the request is
-   usually directed to the cache first.
+   If the client has a cache <xref target="Part6"/> and the request can be
+   satisfied by it, then the request is
+   usually directed there first.
 </t>
 <t>
@@ -2670 +2672 @@
 </t>
 <t>
-   A non-transforming proxy &MUST; preserve the message payload (&payload;).
-   A transforming proxy &MUST; preserve the payload of a message that
+   A non-transforming proxy &MUST-NOT; modify the message payload (&payload;).
+   A transforming proxy &MUST-NOT; modify the payload of a message that
    contains the no-transform cache-control directive.
 </t>
@@ -3101 +3103 @@
   <x:ref>protocol-version</x:ref> = <x:ref>token</x:ref>
 </artwork></figure>
-<t>
-   For example,
-</t>
-<figure><artwork type="example">
-  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+<figure><preamble>
+   The following is a hypothetical example sent by a client:
+</preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
+GET /hello.txt HTTP/1.1
+Host: www.example.com
+Connection: upgrade
+Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+
 </artwork></figure>
 <t>
@@ -3134 +3139 @@
    protocol; an OPTIONS request can be honored by any protocol.
 </t>
+<figure><preamble>
+   The following is an example response to the above hypothetical request:
+</preamble><artwork type="message/http; msgtype=&#34;response&#34;" x:indent-with="  ">
+HTTP/1.1 101 Switching Protocols
+Connection: upgrade
+Upgrade: HTTP/2.0
+
+[... data stream switches to HTTP/2.0 with an appropriate response
+(as defined by new protocol) to the "GET /hello.txt" request ...]
+</artwork></figure>
 <t>
    When Upgrade is sent, a sender &MUST; also send a 
@@ -3631 +3646 @@
    This specification also provides a way for servers to reject messages that
    have request-targets that are too long (&status-414;) or request entities
-   that are too large (&status-4xx;).
+   that are too large (&status-4xx;). Additional status codes related to
+   capacity limits have been defined by extensions to HTTP
+   <xref target="RFC6585"/>.
 </t>
 <t>
@@ -4639 +4656 @@
 </reference>
 
+<reference anchor='RFC6585'>
+  <front>
+    <title>Additional HTTP Status Codes</title>
+    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
+      <organization>Rackspace</organization>
+    </author>
+    <author initials='R.' surname='Fielding' fullname='R. Fielding'>
+      <organization>Adobe</organization>
+    </author>
+    <date year='2012' month='April' />
+   </front>
+   <seriesInfo name='RFC' value='6585' />
+</reference>
+
 <!--<reference anchor='BCP97'>
   <front>