Ignore:
Timestamp:
Feb 28, 2012, 12:46:03 AM (8 years ago)
Author:
fielding@…
Message:

Update treansfer-encoding and content-length definitions to match
prior decisions on message body length parsing.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1549 r1550  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 30, 2012";
     462       content: "Expires August 31, 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-02-27">
     512      <meta name="dct.issued" scheme="ISO8601" content="2012-02-28">
    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: August 30, 2012</td>
     544               <td class="left">Expires: August 31, 2012</td>
    545545               <td class="right">HP</td>
    546546            </tr>
     
    595595            <tr>
    596596               <td class="left"></td>
    597                <td class="right">February 27, 2012</td>
     597               <td class="right">February 28, 2012</td>
    598598            </tr>
    599599         </tbody>
     
    628628         in progress”.
    629629      </p>
    630       <p>This Internet-Draft will expire on August 30, 2012.</p>
     630      <p>This Internet-Draft will expire on August 31, 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>
     
    14681468      <div id="rfc.iref.h.6"></div>
    14691469      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3>
    1470       <p id="rfc.section.3.3.1.p.1">When one or more transfer encodings are applied to a payload body in order to form the message body, a Transfer-Encoding header
    1471          field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer encodings are defined
     1470      <p id="rfc.section.3.3.1.p.1">When one or more transfer codings are applied to a payload body in order to form the message body, a Transfer-Encoding header
     1471         field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer codings are defined
    14721472         in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>.
    14731473      </p>
     
    14821482         applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection.
    14831483      </p>
    1484       <p id="rfc.section.3.3.1.p.5">For example,</p>
    1485       <div id="rfc.figure.u.35"></div><pre class="text">  Transfer-Encoding: chunked
    1486 </pre><p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
    1487       </p>
    1488       <p id="rfc.section.3.3.1.p.8">Unlike Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1484      <div id="rfc.figure.u.35"></div>
     1485      <p>For example,</p><pre class="text">  Transfer-Encoding: gzip, chunked
     1486</pre><p>indicates that the payload body has been compressed using the gzip coding and then chunked using the chunked coding while
     1487         forming the message body.
     1488      </p>
     1489      <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
     1490      </p>
     1491      <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1492      </p>
     1493      <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a 304 response to a GET request, neither of which includes a message body, to
     1494         indicate that the origin server would have applied a transfer coding to the message body if the request had been an unconditional
     1495         GET. This indication is not required, however, because any recipient on the response chain (including the origin server) can
     1496         remove transfer codings when they are not needed.
    14891497      </p>
    14901498      <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
     
    14971505      <div id="rfc.iref.h.7"></div>
    14981506      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h3>
    1499       <p id="rfc.section.3.3.2.p.1">The "Content-Length" header field indicates the size of the message body, in decimal number of octets, for any message other
    1500          than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length
    1501          indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request
    1502          been a GET. In the case of a 304 (Not Modified) response to a GET request, Content-Length indicates the size of the payload
    1503          body (not including any potential transfer-coding) that would have been sent in a 200 (OK) response.
     1507      <p id="rfc.section.3.3.2.p.1">When a message does not have a Transfer-Encoding header field and the payload body length can be determined prior to being
     1508         transferred, a Content-Length header field <em class="bcp14">SHOULD</em> be sent to indicate the length of the payload body that is either present as the message body, for requests and non-HEAD responses
     1509         other than 304, or would have been present had the request been an unconditional GET. The length is expressed as a decimal
     1510         number of octets.
    15041511      </p>
    15051512      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    15061513</pre><p id="rfc.section.3.3.2.p.3">An example is</p>
    15071514      <div id="rfc.figure.u.37"></div><pre class="text">  Content-Length: 3495
    1508 </pre><p id="rfc.section.3.3.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message body length when no transfer-coding is being applied and the payload's body length
    1509          can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message body.
    1510       </p>
    1511       <p id="rfc.section.3.3.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p>
    1512       <p id="rfc.section.3.3.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is
    1513          an optional field used within the "message/external-body" content-type.
    1514       </p>
    1515       <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
     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         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
     1521         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>).
     1522      </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
    15161524         a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields
    15171525         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
    15181526         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.
    15191530      </p>
    15201531      <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>
     
    20222033      <ul>
    20232034         <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields
    2024             in responses MUST be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry.
     2035            in responses <em class="bcp14">MUST</em> be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry.
    20252036         </li>
    20262037         <li>Hop-by-hop header fields, which are meaningful only for a single transport-level connection, and are not stored by caches
Note: See TracChangeset for help on using the changeset viewer.