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.

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.