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

Timestamp:

05/12/12 17:42:21 (9 years ago)

Author:

fielding@…

Message:

(editorial) improvements to persistent connections section; addresses #396

File:

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

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

@@ -2779 +2779 @@
 </t>
 <t>
-   A client that does not support persistent connections &MUST;
+   A client that does not support <x:ref>persistent connections</x:ref> &MUST;
    send the "close" connection option in every request message.
 </t>
 <t>
-   A server that does not support persistent connections &MUST;
+   A server that does not support <x:ref>persistent connections</x:ref> &MUST;
    send the "close" connection option in every response message that
    does not have a <x:ref>1xx (Informational)</x:ref> status code.
@@ -2789 +2789 @@
 </section>
 
-<section title="Persistent Connections" anchor="persistent.connections">
-  <x:anchor-alias value="persistent connections"/>
-<t>
-   HTTP was originally designed to use a separate connection for each
-   request/response pair. As the Web evolved and embedded requests became
-   common for inline images, the connection establishment overhead was
-   a significant drain on performance and a concern for Internet congestion.
-   Message framing (via <x:ref>Content-Length</x:ref>) and optional
-   long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order
-   to improve performance for some requests. However, these extensions were
-   insufficient for dynamically generated responses and difficult to use
-   with intermediaries.
-</t>
-<t>
-   HTTP/1.1 defaults to the use of "<x:ref>persistent connections</x:ref>",
-   which allow multiple requests and responses to be carried over a single
-   connection. The "<x:ref>close</x:ref>" connection-option is used to
-   signal that a connection will close after the current request/response.
-   Persistent connections have a number of advantages:
-  <list style="symbols">
-      <t>
-        By opening and closing fewer connections, CPU time is saved
-        in routers and hosts (clients, servers, proxies, gateways,
-        tunnels, or caches), and memory used for protocol control
-        blocks can be saved in hosts.
-      </t>
-      <t>
-        Most requests and responses can be pipelined on a connection.
-        Pipelining allows a client to make multiple requests without
-        waiting for each response, allowing a single connection to
-        be used much more efficiently and with less overall latency.
-      </t>
-      <t>
-        For TCP connections, network congestion is reduced by eliminating the
-        packets associated with the three way handshake and graceful close
-        procedures, and by allowing sufficient time to determine the
-        congestion state of the network.
-      </t>
-      <t>
-        Latency on subsequent requests is reduced since there is no time
-        spent in the connection opening handshake.
-      </t>
-      <t>
-        HTTP can evolve more gracefully, since most errors can be reported
-        without the penalty of closing the connection. Clients using
-        future versions of HTTP might optimistically try a new feature,
-        but if communicating with an older server, retry with old
-        semantics after an error is reported.
-      </t>
-    </list>
-</t>
-<t>
-   HTTP implementations &SHOULD; implement persistent connections.
-</t>
-   
 <section title="Establishment" anchor="persistent.establishment">
 <t>
@@ -2849 +2794 @@
    are established via various transport or session-layer protocols.
    Each connection applies to only one transport link.
+</t>
+</section>
+
+<section title="Persistence" anchor="persistent.connections">
+   <x:anchor-alias value="persistent connections"/>
+<t>
+   HTTP/1.1 defaults to the use of "<x:dfn>persistent connections</x:dfn>",
+   which allow multiple requests and responses to be carried over a single
+   connection. The "<x:ref>close</x:ref>" connection-option is used to signal
+   that a connection will not persist after the current request/response.
+   HTTP implementations &SHOULD; support persistent connections.
 </t>
 <t>
@@ -2872 +2828 @@
    implemented by many HTTP/1.0 clients).
 </t>
-</section>
-
-<section title="Reuse" anchor="persistent.reuse">
 <t>
    In order to remain persistent, all messages on a connection &MUST;
@@ -2880 +2833 @@
    of the connection), as described in <xref target="message.body"/>.
 </t>
+</section>
+
+<section title="Reuse" anchor="persistent.reuse">
 <t>
    A server &MAY; assume that an HTTP/1.1 client intends to maintain a
@@ -3066 +3022 @@
    be found in other transport connection protocols.
 </t>
-</section>
 </section>