Changeset 1492 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

14/12/11 03:21:58 (11 years ago)

Author:

mnot@…

Message:

Clarify Proxy-Connection; #158

File:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (10 diffs)

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

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires June 13, 2012"; 
+       content: "Expires June 16, 2012"; 
   } 
   @bottom-right {
@@ -409 +409 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-12-11">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-12-14">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -441 +441 @@
             </tr>
             <tr>
-               <td class="left">Expires: June 13, 2012</td>
+               <td class="left">Expires: June 16, 2012</td>
                <td class="right">HP</td>
             </tr>
@@ -494 +494 @@
             <tr>
                <td class="left"></td>
-               <td class="right">December 11, 2011</td>
+               <td class="right">December 14, 2011</td>
             </tr>
          </tbody>
@@ -527 +527 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 13, 2012.</p>
+      <p>This Internet-Draft will expire on June 16, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -2937 +2937 @@
       </p>
       <h3 id="rfc.section.A.1.2"><a href="#rfc.section.A.1.2">A.1.2</a>&nbsp;<a id="compatibility.with.http.1.0.persistent.connections" href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></h3>
-      <p id="rfc.section.A.1.2.p.1">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the
-         server after sending the response. However, some implementations implement the Keep-Alive version of persistent connections
+      <p id="rfc.section.A.1.2.p.1">In HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the
+         response. However, some implementations implement the explicitly negotiated ("Keep-Alive") version of persistent connections
          described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
       </p>
-      <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.0
-         clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0
-         experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify
-         these problems. The problem was that some existing HTTP/1.0 clients might send Keep-Alive to a proxy server that doesn't understand
-         Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection
-         and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented
-         from using Keep-Alive when talking to proxies.
-      </p>
-      <p id="rfc.section.A.1.2.p.3">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable.
-         Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when
-         talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce
-         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section&nbsp;8.1</a>.
+      <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly
+         negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0
+         persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand Connection, it will erroneously
+         forward that header to the next inbound server, which would result in a hung connection.
+      </p>
+      <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header, targeted specifically at proxies. In practice, this
+         was also unworkable, because proxies are often deployed in multiple layers, bringing about the same problem discussed above.
+      </p>
+      <p id="rfc.section.A.1.2.p.4">As a result, clients are encouraged not to send the Proxy-Connection header in any requests.</p>
+      <p id="rfc.section.A.1.2.p.5">Clients are also encouraged to consider the use of Connection: keep-alive in requests carefully; while they can enable persistent
+         connections with HTTP/1.0 servers, clients using them need will need to monitor the connection for "hung" requests (which
+         indicate that the client ought stop sending the header), and this mechanism ought not be used by clients at all when a proxy
+         is being used.
       </p>
       <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
@@ -2986 +2987 @@
       <p id="rfc.section.A.2.p.12">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;8</a>)
       </p>
-      <p id="rfc.section.A.2.p.13">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.13" title="Connection">Section&nbsp;8.1</a>)
+      <p id="rfc.section.A.2.p.13">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section&nbsp;8.1</a>)
       </p>
       <p id="rfc.section.A.2.p.14">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.7</a>)
@@ -3494 +3495 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/324">http://tools.ietf.org/wg/httpbis/trac/ticket/324</a>&gt;: "Intermediary rewriting of queries"
          </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/158">http://tools.ietf.org/wg/httpbis/trac/ticket/158</a>&gt;: "Proxy-Connection and Keep-Alive"
+         </li>
       </ul>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
@@ -3528 +3531 @@
                   <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">5.1.2.1</a></li>
                   <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
-                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
+                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.c.12"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
                   <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.c.13"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
                </ul>
@@ -3642 +3645 @@
                   <li>Header Fields&nbsp;&nbsp;
                      <ul>
-                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.1.2</a>, <a href="#rfc.xref.header.connection.13">A.2</a></li>
+                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">6.1.2</a>, <a href="#rfc.xref.header.connection.5">6.1.3</a>, <a href="#rfc.xref.header.connection.6">6.1.3.1</a>, <a href="#rfc.xref.header.connection.7">8</a>, <a href="#rfc.iref.h.6"><b>8.1</b></a>, <a href="#rfc.xref.header.connection.8">8.4</a>, <a href="#rfc.xref.header.connection.9">8.7</a>, <a href="#rfc.xref.header.connection.10">9.1</a>, <a href="#rfc.xref.header.connection.11">9.1</a>, <a href="#rfc.xref.header.connection.12">A.2</a></li>
                         <li>Content-Length&nbsp;&nbsp;<a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.xref.header.content-length.2">8</a>, <a href="#rfc.iref.h.7"><b>8.2</b></a>, <a href="#rfc.xref.header.content-length.3">9.1</a></li>
                         <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.xref.header.host.2">8</a>, <a href="#rfc.iref.h.9"><b>8.3</b></a>, <a href="#rfc.xref.header.host.3">9.1</a>, <a href="#rfc.xref.header.host.4">A.1.1</a></li>