Changeset 1570


Ignore:
Timestamp:
Mar 9, 2012, 12:46:33 AM (8 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.

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

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

    r1567 r1570  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 9, 2012";
     462       content: "Expires September 10, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    510510      <meta name="dct.creator" content="Reschke, J. F.">
    511511      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    512       <meta name="dct.issued" scheme="ISO8601" content="2012-03-08">
     512      <meta name="dct.issued" scheme="ISO8601" content="2012-03-09">
    513513      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    514514      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    542542            </tr>
    543543            <tr>
    544                <td class="left">Expires: September 9, 2012</td>
     544               <td class="left">Expires: September 10, 2012</td>
    545545               <td class="right">HP</td>
    546546            </tr>
    … …  
    595595            <tr>
    596596               <td class="left"></td>
    597                <td class="right">March 8, 2012</td>
     597               <td class="right">March 9, 2012</td>
    598598            </tr>
    599599         </tbody>
    … …  
    628628         in progress”.
    629629      </p>
    630       <p>This Internet-Draft will expire on September 9, 2012.</p>
     630      <p>This Internet-Draft will expire on September 10, 2012.</p>
    631631      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    632632      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    14631463         status code (<a href="#status.code" title="Status Code">Section&nbsp;3.1.2.1</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g.,
    14641464         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
    1465          All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length.
     1465         Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), 204
     1466         (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length.
    14661467      </p>
    14671468      <div id="rfc.iref.t.4"></div>
    … …  
    15131514</pre><p id="rfc.section.3.3.2.p.3">An example is</p>
    15141515      <div id="rfc.figure.u.37"></div><pre class="text">  Content-Length: 3495
    1515 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (not including any potential
     1516</pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential
    15161517         transfer-coding) that would have been sent had the request been a GET. In the case of a 304 (Not Modified) response to a GET
    1517          request, Content-Length indicates the size of the payload body (not including any potential transfer-coding) that would have
    1518          been sent in a 200 (OK) response.
    1519       </p>
    1520       <p id="rfc.section.3.3.2.p.6">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
     1518         request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would have been
     1519         sent in a 200 (OK) response.
     1520      </p>
     1521      <p id="rfc.section.3.3.2.p.6">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only
     1522         within the "message/external-body" media-type.
     1523      </p>
     1524      <p id="rfc.section.3.3.2.p.7">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
    15211525         an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Protocol Element Size Overflows">Section&nbsp;10.6</a>).
    15221526      </p>
    1523       <p id="rfc.section.3.3.2.p.7">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
     1527      <p id="rfc.section.3.3.2.p.8">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
    15241528         a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields
    15251529         have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing
    15261530         that decimal value prior to determining the message body length.
    1527       </p>
    1528       <p id="rfc.section.3.3.2.p.8">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only
    1529          within the "message/external-body" media-type.
    15301531      </p>
    15311532      <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="message.body.length" href="#message.body.length">Message Body Length</a></h3>
    … …  
    15371538               empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message
    15381539               body.
     1540            </p>
     1541         </li>
     1542         <li>
     1543            <p>Any successful (2xx) response to a CONNECT request implies that the connection will become a tunnel immediately after the
     1544               empty line that concludes the header fields. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in such a message.
    15391545            </p>
    15401546         </li>

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

    r1567 r1570  
    15761576   Content-Length, etc.) only indicate what their values would have been
    15771577   if the request method had been GET.
     1578   Successful (2xx) responses to CONNECT switch to tunnel mode instead of
     1579   having a message body.
    15781580   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
    15791581   responses &MUST-NOT; include a message body.
    … …  
    16931695<t>
    16941696   In the case of a response to a HEAD request, Content-Length indicates
    1695    the size of the payload body (not including any potential transfer-coding)
     1697   the size of the payload body (without any potential transfer-coding)
    16961698   that would have been sent had the request been a GET.
    16971699   In the case of a 304 (Not Modified) response to a GET request,
    1698    Content-Length indicates the size of the payload body (not including
     1700   Content-Length indicates the size of the payload body (without
    16991701   any potential transfer-coding) that would have been sent in a 200 (OK)
    17001702   response.
     1703</t>
     1704<t>
     1705   HTTP's use of Content-Length is significantly different from how it is
     1706   used in MIME, where it is an optional field used only within the
     1707   "message/external-body" media-type.
    17011708</t>
    17021709<t>
    … …  
    17191726   length.
    17201727</t>
    1721 <t>
    1722    HTTP's use of Content-Length is significantly different from how it is
    1723    used in MIME, where it is an optional field used only within the
    1724    "message/external-body" media-type.
    1725 </t>
    17261728</section>
    17271729
    … …  
    17381740     empty line after the header fields, regardless of the header
    17391741     fields present in the message, and thus cannot contain a message body.
     1742    </t></x:lt>
     1743    <x:lt><t>
     1744     Any successful (2xx) response to a CONNECT request implies that the
     1745     connection will become a tunnel immediately after the empty line that
     1746     concludes the header fields.  A client &MUST; ignore any Content-Length
     1747     or Transfer-Encoding header fields received in such a message.
    17401748    </t></x:lt>
    17411749    <x:lt><t>

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

    r1567 r1570  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 9, 2012";
     462       content: "Expires September 10, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    513513      <meta name="dct.creator" content="Reschke, J. F.">
    514514      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    515       <meta name="dct.issued" scheme="ISO8601" content="2012-03-08">
     515      <meta name="dct.issued" scheme="ISO8601" content="2012-03-09">
    516516      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    517517      <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.">
    … …  
    544544            </tr>
    545545            <tr>
    546                <td class="left">Expires: September 9, 2012</td>
     546               <td class="left">Expires: September 10, 2012</td>
    547547               <td class="right">HP</td>
    548548            </tr>
    … …  
    597597            <tr>
    598598               <td class="left"></td>
    599                <td class="right">March 8, 2012</td>
     599               <td class="right">March 9, 2012</td>
    600600            </tr>
    601601         </tbody>
    … …  
    627627         in progress”.
    628628      </p>
    629       <p>This Internet-Draft will expire on September 9, 2012.</p>
     629      <p>This Internet-Draft will expire on September 10, 2012.</p>
    630630      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    631631      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    693693               <li>6.7&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li>
    694694               <li>6.8&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li>
    695                <li>6.9&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a><ul>
    696                      <li>6.9.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.9.1">Establishing a Tunnel with CONNECT</a></li>
    697                   </ul>
    698                </li>
     695               <li>6.9&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li>
    699696            </ul>
    700697         </li>
    … …  
    16741671      <div id="rfc.iref.m.8"></div>
    16751672      <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a>&nbsp;<a id="CONNECT" href="#CONNECT">CONNECT</a></h2>
    1676       <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
    1677          forwarding of packets until the connection is closed.
     1673      <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
     1674         its behavior to blind forwarding of packets until the connection is closed.
    16781675      </p>
    16791676      <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.
    … …  
    16831680Host: server.example.com:80
    16841681
    1685 </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
    1686          tunnel must be established first.
    1687       </p>
    1688       <p id="rfc.section.6.9.p.5">For example, proxy authentication might be used to establish the authority to create a tunnel:</p>
     1682</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
     1683         host and port, and has switched to tunneling the current connection to that server connection. The tunneled data from the
     1684         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.
     1685      </p>
     1686      <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
     1687         governed by HTTP.
     1688      </p>
     1689      <p id="rfc.section.6.9.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p>
    16891690      <div id="rfc.figure.u.7"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1
    16901691Host: server.example.com:80
    16911692Proxy-Authorization: basic aGVsbG86d29ybGQ=
    16921693
    1693 </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
    1694          implementations to reject the request.
    1695       </p>
    1696       <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
    1697          also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if
    1698          more than one TCP segment is outstanding.
    1699       </p>
    1700       <h3 id="rfc.section.6.9.1"><a href="#rfc.section.6.9.1">6.9.1</a>&nbsp;Establishing a Tunnel with CONNECT
    1701       </h3>
    1702       <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
    1703          host and port, and has switched to tunneling the current connection to that server connection.
    1704       </p>
    1705       <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
     1694</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
     1695         to reject the request.
     1696      </p>
     1697      <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
     1698         if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding.
     1699      </p>
     1700      <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
    17061701         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.
    17071702      </p>
    1708       <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.
    1709       </p>
    1710       <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
     1703      <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
    17111704         the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
    17121705         peer undelivered, that data will be discarded.
     1706      </p>
     1707      <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
     1708         CONNECT.
    17131709      </p>
    17141710      <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>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1567 r1570  
    12951295<t>
    12961296   The CONNECT method requests that the proxy establish a tunnel
    1297    to the request-target and then restrict its behavior to blind
    1298    forwarding of packets until the connection is closed.
     1297   to the request-target and, if successful, thereafter restrict its behavior
     1298   to blind forwarding of packets until the connection is closed.
    12991299</t>
    13001300<t>
    … …  
    13101310</artwork></figure>
    13111311<t>
    1312    Other HTTP mechanisms can be used normally with the CONNECT method &mdash;
    1313    except end-to-end protocol Upgrade requests, since the
    1314    tunnel must be established first.
    1315 </t>
    1316 <t>
    1317    For example, proxy authentication might be used to establish the
     1312   Any successful (2xx) response to a CONNECT request indicates that the
     1313   proxy has established a connection to the requested host and port,
     1314   and has switched to tunneling the current connection to that server
     1315   connection.
     1316   The tunneled data from the server begins immediately after the blank line
     1317   that concludes the successful response's header block.
     1318   A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length
     1319   header fields in a successful response.
     1320   A client &MUST; ignore any Content-Length or Transfer-Encoding header
     1321   fields received in a successful response.
     1322</t>
     1323<t>
     1324   Any response other than a successful response indicates that the tunnel
     1325   has not yet been formed and that the connection remains governed by HTTP.
     1326</t>
     1327<t>
     1328   Proxy authentication might be used to establish the
    13181329   authority to create a tunnel:
    13191330</t>
    … …  
    13251336</artwork></figure>
    13261337<t>
    1327    Bodies on CONNECT requests have no defined semantics. Note that sending a body
    1328    on a CONNECT request might cause some existing implementations to reject the
    1329    request.
    1330 </t>
    1331 <t>
    1332    Like any other pipelined HTTP/1.1 request, data to be tunnel may be
    1333    sent immediately after the blank line. The usual caveats also apply:
     1338   A message body on a CONNECT request has no defined semantics. Sending a
     1339   body on a CONNECT request might cause existing implementations to reject
     1340   the request.
     1341</t>
     1342<t>
     1343   Similar to a pipelined HTTP/1.1 request, data to be tunneled from client
     1344   to server &MAY; be sent immediately after the request (before a response
     1345   is received). The usual caveats also apply:
    13341346   data may be discarded if the eventual response is negative, and the
    13351347   connection may be reset with no response if more than one TCP segment
    13361348   is outstanding.
    1337 </t>
    1338 
    1339 <section title="Establishing a Tunnel with CONNECT">
    1340 <t>
    1341    Any successful (2xx) response to a CONNECT request indicates that the
    1342    proxy has established a connection to the requested host and port,
    1343    and has switched to tunneling the current connection to that server
    1344    connection.
    13451349</t>
    13461350<t>
    … …  
    13531357</t>
    13541358<t>
    1355    An origin server which receives a CONNECT request for itself &MAY;
    1356    respond with a 2xx status code to indicate that a connection is
    1357    established.
    1358 </t>
    1359 <t>
    13601359   If at any point either one of the peers gets disconnected, any
    13611360   outstanding data that came from that peer will be passed to the other
    … …  
    13641363   that data will be discarded.
    13651364</t>
    1366 
    1367 </section>
     1365<t>
     1366   An origin server which receives a CONNECT request for itself &MAY;
     1367   respond with a 2xx status code to indicate that a connection is
     1368   established.  However, most origin servers do not implement CONNECT.
     1369</t>
    13681370</section>
    13691371</section>
Note: See TracChangeset for help on using the changeset viewer.