Changeset 1570 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

09/03/12 08:46:33 (9 years ago)

Author:

fielding@…

Message:

#250 message-body in CONNECT response

Change message body parsing of successful CONNECT responses such that
the tunnel begins immediately after the header block, as implemented in
practice, and any Content-Length or Transfer-Encoding is ignored.

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (8 diffs)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -460 +460 @@
   } 
   @bottom-center {
-       content: "Expires September 9, 2012"; 
+       content: "Expires September 10, 2012"; 
   } 
   @bottom-right {
@@ -513 +513 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-03-08">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-03-09">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
@@ -544 +544 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 9, 2012</td>
+               <td class="left">Expires: September 10, 2012</td>
                <td class="right">HP</td>
             </tr>
@@ -597 +597 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 8, 2012</td>
+               <td class="right">March 9, 2012</td>
             </tr>
          </tbody>
@@ -627 +627 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on September 9, 2012.</p>
+      <p>This Internet-Draft will expire on September 10, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -693 +693 @@
                <li>6.7&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
                <li>6.8&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
-               <li>6.9&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a><ul>
-                     <li>6.9.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.9.1">Establishing a Tunnel with CONNECT</a></li>
-                  </ul>
-               </li>
+               <li>6.9&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
             </ul>
          </li>
@@ -1674 +1671 @@
       <div id="rfc.iref.m.8"></div>
       <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h2>
-      <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and then restrict its behavior to blind
-         forwarding of packets until the connection is closed.
+      <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict
+         its behavior to blind forwarding of packets until the connection is closed.
       </p>
       <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
@@ -1683 +1680 @@
 Host: server.example.com:80
 
-</pre><p id="rfc.section.6.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method — except end-to-end protocol Upgrade requests, since the
-         tunnel must be established first.
-      </p>
-      <p id="rfc.section.6.9.p.5">For example, proxy authentication might be used to establish the authority to create a tunnel:</p>
+</pre><p id="rfc.section.6.9.p.4">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested
+         host and port, and has switched to tunneling the current connection to that server connection. The tunneled data from the
+         server begins immediately after the blank line that concludes the successful response's header block. A server <em class="bcp14">SHOULD NOT</em> send any Transfer-Encoding or Content-Length header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
+      </p>
+      <p id="rfc.section.6.9.p.5">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
+         governed by HTTP.
+      </p>
+      <p id="rfc.section.6.9.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p>
       <div id="rfc.figure.u.7"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80
 Proxy-Authorization: basic aGVsbG86d29ybGQ=
 
-</pre><p id="rfc.section.6.9.p.7">Bodies on CONNECT requests have no defined semantics. Note that sending a body on a CONNECT request might cause some existing
-         implementations to reject the request.
-      </p>
-      <p id="rfc.section.6.9.p.8">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats
-         also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if
-         more than one TCP segment is outstanding.
-      </p>
-      <h3 id="rfc.section.6.9.1"><a href="#rfc.section.6.9.1">6.9.1</a>&nbsp;Establishing a Tunnel with CONNECT
-      </h3>
-      <p id="rfc.section.6.9.1.p.1">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested
-         host and port, and has switched to tunneling the current connection to that server connection.
-      </p>
-      <p id="rfc.section.6.9.1.p.2">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the
+</pre><p id="rfc.section.6.9.p.8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
+         to reject the request.
+      </p>
+      <p id="rfc.section.6.9.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data may be discarded
+         if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding.
+      </p>
+      <p id="rfc.section.6.9.p.10">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the
          first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority.
       </p>
-      <p id="rfc.section.6.9.1.p.3">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established.
-      </p>
-      <p id="rfc.section.6.9.1.p.4">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
+      <p id="rfc.section.6.9.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
          the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
          peer undelivered, that data will be discarded.
+      </p>
+      <p id="rfc.section.6.9.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. However, most origin servers do not implement
+         CONNECT.
       </p>
       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="status.codes" href="#status.codes">Status Code Definitions</a></h1>