Changeset 1550


Ignore:
Timestamp:
28/02/12 08:46:03 (11 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 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

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

    r1549 r1550  
    15861586  <x:anchor-alias value="Transfer-Encoding"/>
    15871587<t>
    1588    When one or more transfer encodings are applied to a payload body in order
     1588   When one or more transfer codings are applied to a payload body in order
    15891589   to form the message body, a Transfer-Encoding header field &MUST; be sent
    15901590   in the message and &MUST; contain the list of corresponding
    15911591   transfer-coding names in the same order that they were applied.
    1592    Transfer encodings are defined in <xref target="transfer.codings"/>.
     1592   Transfer codings are defined in <xref target="transfer.codings"/>.
    15931593</t>
    15941594<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/>
    … …  
    16191619   the message &MUST; be terminated by closing the connection.
    16201620</t>
    1621 <t>
     1621<figure><preamble>
    16221622   For example,
    1623 </t>
    1624 <figure><artwork type="example">
    1625   Transfer-Encoding: chunked
    1626 </artwork></figure>
     1623</preamble><artwork type="example">
     1624  Transfer-Encoding: gzip, chunked
     1625</artwork><postamble>
     1626   indicates that the payload body has been compressed using the gzip
     1627   coding and then chunked using the chunked coding while forming the
     1628   message body.
     1629</postamble></figure>
    16271630<t>
    16281631   If more than one Transfer-Encoding header field is present in a message,
    … …  
    16371640   Additional information about the encoding parameters &MAY; be provided
    16381641   by other header fields not defined by this specification.
     1642</t>
     1643<t>
     1644   Transfer-Encoding &MAY; be sent in a response to a HEAD request or in a
     1645   304 response to a GET request, neither of which includes a message body,
     1646   to indicate that the origin server would have applied a transfer coding
     1647   to the message body if the request had been an unconditional GET.
     1648   This indication is not required, however, because any recipient on
     1649   the response chain (including the origin server) can remove transfer
     1650   codings when they are not needed.
    16391651</t>
    16401652<t>
    … …  
    16611673  <x:anchor-alias value="Content-Length"/>
    16621674<t>
    1663    The "Content-Length" header field indicates the size of the
    1664    message body, in decimal number of octets, for any message other than
    1665    a response to a HEAD request or a response with a status code of 304.
     1675   When a message does not have a Transfer-Encoding header field and the
     1676   payload body length can be determined prior to being transferred, a
     1677   Content-Length header field &SHOULD; be sent to indicate the length of the
     1678   payload body that is either present as the message body, for requests
     1679   and non-HEAD responses other than 304, or would have been present had
     1680   the request been an unconditional GET.  The length is expressed as a
     1681   decimal number of octets.
     1682</t>
     1683<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>
     1684  <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref>
     1685</artwork></figure>
     1686<t>
     1687   An example is
     1688</t>
     1689<figure><artwork type="example">
     1690  Content-Length: 3495
     1691</artwork></figure>
     1692<t>
    16661693   In the case of a response to a HEAD request, Content-Length indicates
    16671694   the size of the payload body (not including any potential transfer-coding)
    … …  
    16721699   response.
    16731700</t>
    1674 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/>
    1675   <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref>
    1676 </artwork></figure>
    1677 <t>
    1678    An example is
    1679 </t>
    1680 <figure><artwork type="example">
    1681   Content-Length: 3495
    1682 </artwork></figure>
    1683 <t>
    1684    Implementations &SHOULD; use this field to indicate the message body
    1685    length when no transfer-coding is being applied and the
    1686    payload's body length can be determined prior to being transferred.
    1687    <xref target="message.body"/> describes how recipients determine the length
    1688    of a message body.
    1689 </t>
    1690 <t>
    1691    Any Content-Length greater than or equal to zero is a valid value.
    1692 </t>
    1693 <t>
    1694    Note that the use of this field in HTTP is significantly different from
    1695    the corresponding definition in MIME, where it is an optional field
    1696    used within the "message/external-body" content-type.
     1701<t>
     1702   Any Content-Length field value greater than or equal to zero is valid.
     1703   Since there is no predefined limit to the length of an HTTP payload,
     1704   recipients &SHOULD; anticipate potentially large decimal numerals and
     1705   prevent parsing errors due to integer conversion overflows
     1706   (<xref target="attack.protocol.element.size.overflows"/>).
    16971707</t>
    16981708<t>
    … …  
    17071717   field containing that decimal value prior to determining the message body
    17081718   length.
     1719</t>
     1720<t>
     1721   HTTP's use of Content-Length is significantly different from how it is
     1722   used in MIME, where it is an optional field used only within the
     1723   "message/external-body" media-type.
    17091724</t>
    17101725</section>
    … …  
    26942709      <t>End-to-end header fields, which are  transmitted to the ultimate
    26952710        recipient of a request or response. End-to-end header fields in
    2696         responses MUST be stored as part of a cache entry and &MUST; be
     2711        responses &MUST; be stored as part of a cache entry and &MUST; be
    26972712        transmitted in any response formed from a cache entry.</t>
    26982713
Note: See TracChangeset for help on using the changeset viewer.