Ignore:
Timestamp:
Feb 20, 2012, 1:10:22 AM (8 years ago)
Author:
fielding@…
Message:

Consolidate and clean the description and requirements for Transfer-Encoding

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

Legend:

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

    r1539 r1540  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 22, 2012";
     462       content: "Expires August 23, 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-19">
     512      <meta name="dct.issued" scheme="ISO8601" content="2012-02-20">
    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 22, 2012</td>
     544               <td class="left">Expires: August 23, 2012</td>
    545545               <td class="right">HP</td>
    546546            </tr>
     
    595595            <tr>
    596596               <td class="left"></td>
    597                <td class="right">February 19, 2012</td>
     597               <td class="right">February 20, 2012</td>
    598598            </tr>
    599599         </tbody>
     
    628628         in progress”.
    629629      </p>
    630       <p>This Internet-Draft will expire on August 22, 2012.</p>
     630      <p>This Internet-Draft will expire on August 23, 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>
     
    702702               <li>4.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
    703703               <li>4.3&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
    704                <li>4.4&nbsp;&nbsp;&nbsp;<a href="#associating.request.response">Associating Response to Request</a></li>
     704               <li>4.4&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li>
    705705            </ul>
    706706         </li>
     
    14521452      </p>
    14531453      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
    1454       <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response.</p>
     1454      <p id="rfc.section.3.3.p.1">The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body
     1455         is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;3.3.1</a>.
     1456      </p>
    14551457      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
    1456 </pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
    1457          header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
    1458       </p>
    1459       <p id="rfc.section.3.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
    1460       <p id="rfc.section.3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    1461          in the request's header fields, even if the request method does not define any use for a message-body. This allows the request
    1462          message framing algorithm to be independent of method semantics.
    1463       </p>
    1464       <p id="rfc.section.3.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
    1465          the response 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.,
     1458</pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p>
     1459      <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a Content-Length or Transfer-Encoding header field. Request message
     1460         framing is independent of method semantics, even if the method does not define any use for a message body.
     1461      </p>
     1462      <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
     1463         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.,
    14661464         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
    1467          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         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.
    14681466      </p>
    14691467      <div id="rfc.iref.t.4"></div>
    14701468      <div id="rfc.iref.h.6"></div>
    14711469      <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>
    1472       <p id="rfc.section.3.3.1.p.1">The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs
    1473          from 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>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
    1474          are not.
     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
     1472         in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>.
    14751473      </p>
    14761474      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    1477 </pre><p id="rfc.section.3.3.1.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>. An example is:
    1478       </p>
     1475</pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport
     1476         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is
     1477         primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only
     1478         applied for transport efficiency or security from those that are characteristics of the target resource.
     1479      </p>
     1480      <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size
     1481         is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. If any transfer-coding is applied to a request payload body, the final transfer-coding
     1482         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.
     1483      </p>
     1484      <p id="rfc.section.3.3.1.p.5">For example,</p>
    14791485      <div id="rfc.figure.u.35"></div><pre class="text">  Transfer-Encoding: chunked
    1480 </pre><p id="rfc.section.3.3.1.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    1481       </p>
    1482       <p id="rfc.section.3.3.1.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
    1483       <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.
    1484       </p>
    1485       <p id="rfc.section.3.3.1.p.8">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header
    1486          field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. 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 under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>.
     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.
     1489      </p>
     1490      <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
     1491         not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge
     1492         might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later).
     1493      </p>
     1494      <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection.
    14871495      </p>
    14881496      <div id="rfc.iref.c.6"></div>
     
    15111519      </p>
    15121520      <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>
    1513       <p id="rfc.section.3.3.3.p.1">The length of the message-body is determined by one of the following (in order of precedence):</p>
     1521      <p id="rfc.section.3.3.3.p.1">The length of a message-body is determined by one of the following (in order of precedence):</p>
    15141522      <p id="rfc.section.3.3.3.p.2"> </p>
    15151523      <ol>
     
    15201528         </li>
    15211529         <li>
    1522             <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
     1530            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
    15231531               indicates the data is complete.
    15241532            </p>
     
    17241732      <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
    17251733      </p>
    1726       <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="associating.request.response" href="#associating.request.response">Associating Response to Request</a></h2>
     1734      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    17271735      <p id="rfc.section.4.4.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    17281736         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
     
    17501758  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
    17511759</pre><p id="rfc.section.5.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;5.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
    1752       </p>
    1753       <p id="rfc.section.5.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
    1754          of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic
    1755          of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>), or the desire to encrypt data over a shared transport.
    1756       </p>
    1757       <p id="rfc.section.5.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
    17581760      </p>
    17591761      <div id="rfc.iref.c.7"></div>
     
    18251827      </p>
    18261828      <p id="rfc.section.5.1.p.10">Use of chunk-ext extensions by senders is deprecated; they <em class="bcp14">SHOULD NOT</em> be sent and definition of new chunk-extensions is discouraged.
    1827       </p>
    1828       <p id="rfc.section.5.1.p.11">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting
    1829          messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding
    1830          applied <em class="bcp14">MUST</em> be "chunked". If a 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. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body.
    18311829      </p>
    18321830      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
     
    38483846                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">5.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li>
    38493847                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">5.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li>
    3850                   <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">5</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
    3851                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">5</a></li>
     3848                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>12.2</b></a><ul>
     3849                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">3.3.1</a></li>
    38523850                     </ul>
    38533851                  </li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1538 r1540  
    15501550  <x:anchor-alias value="message-body"/>
    15511551<t>
    1552    The message-body (if any) of an HTTP message is used to carry the
    1553    payload body associated with the request or response.
     1552   The message body (if any) of an HTTP message is used to carry the
     1553   payload body of that request or response.  The message body is
     1554   identical to the payload body unless a transfer coding has been
     1555   applied, as described in <xref target="header.transfer-encoding"/>.
    15541556</t>
    15551557<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-body"/>
     
    15571559</artwork></figure>
    15581560<t>
    1559    The message-body differs from the payload body only when a transfer-coding
    1560    has been applied, as indicated by the Transfer-Encoding header field
    1561    (<xref target="header.transfer-encoding"/>).
    1562 </t>
    1563 <t>
    1564    The rules for when a message-body is allowed in a message differ for
     1561   The rules for when a message body is allowed in a message differ for
    15651562   requests and responses.
    15661563</t>
    15671564<t>
    1568    The presence of a message-body in a request is signaled by the
    1569    inclusion of a Content-Length or Transfer-Encoding header field in
    1570    the request's header fields, even if the request method does not
    1571    define any use for a message-body.  This allows the request
    1572    message framing algorithm to be independent of method semantics.
    1573 </t>
    1574 <t>
    1575    For response messages, whether or not a message-body is included with
    1576    a message is dependent on both the request method and the response
     1565   The presence of a message body in a request is signaled by a
     1566   a Content-Length or Transfer-Encoding header field.
     1567   Request message framing is independent of method semantics,
     1568   even if the method does not define any use for a message body.
     1569</t>
     1570<t>
     1571   The presence of a message body in a response depends on both
     1572   the request method to which it is responding and the response
    15771573   status code (<xref target="status.code"/>).
    1578    Responses to the HEAD request method never include a message-body
     1574   Responses to the HEAD request method never include a message body
    15791575   because the associated response header fields (e.g., Transfer-Encoding,
    15801576   Content-Length, etc.) only indicate what their values would have been
    1581    if the request method had been GET.  All 1xx (Informational), 204 (No Content),
    1582    and 304 (Not Modified) responses &MUST-NOT; include a message-body.
     1577   if the request method had been GET.
     1578   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
     1579   responses &MUST-NOT; include a message body.
    15831580   All other responses do include a message-body, although the body
    15841581   &MAY; be of zero length.
     
    15901587  <x:anchor-alias value="Transfer-Encoding"/>
    15911588<t>
    1592    The "Transfer-Encoding" header field indicates what transfer-codings
    1593    (if any) have been applied to the message body. It differs from
    1594    Content-Encoding (&content-codings;) in that transfer-codings are a property
    1595    of the message (and therefore are removed by intermediaries), whereas
    1596    content-codings are not.
     1589   When one or more transfer encodings are applied to a payload body in order
     1590   to form the message-body, a Transfer-Encoding header field &MUST; be sent
     1591   in the message and &MUST; contain the list of corresponding
     1592   transfer-coding names in the same order that they were applied.
     1593   Transfer encodings are defined in <xref target="transfer.codings"/>.
    15971594</t>
    15981595<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/>
     
    16001597</artwork></figure>
    16011598<t>
    1602    Transfer-codings are defined in <xref target="transfer.codings"/>. An example is:
     1599   Transfer-Encoding is analogous to the Content-Transfer-Encoding field of
     1600   MIME, which was designed to enable safe transport of binary data over a
     1601   7-bit transport service (<xref target="RFC2045" x:fmt="," x:sec="6"/>).
     1602   However, safe transport has a different focus for an 8bit-clean transfer
     1603   protocol. In HTTP's case, Transfer-Encoding is primarily intended to
     1604   accurately delimit a dynamically generated payload and to distinguish
     1605   payload encodings that are only applied for transport efficiency or
     1606   security from those that are characteristics of the target resource.
     1607</t>
     1608<t>
     1609   The "chunked" transfer-coding (<xref target="chunked.encoding"/>)
     1610   &MUST; be implemented by all HTTP/1.1 recipients because it plays a
     1611   crucial role in delimiting messages when the payload body size is not
     1612   known in advance.
     1613   When the "chunked" transfer-coding is used, it &MUST; be the last
     1614   transfer-coding applied to form the message body and &MUST-NOT;
     1615   be applied more than once in a message-body.
     1616   If any transfer-coding is applied to a request payload body,
     1617   the final transfer-coding applied &MUST; be "chunked".
     1618   If any transfer-coding is applied to a response payload body, then either
     1619   the final transfer-coding applied &MUST; be "chunked" or
     1620   the message &MUST; be terminated by closing the connection.
     1621</t>
     1622<t>
     1623   For example,
    16031624</t>
    16041625<figure><artwork type="example">
     
    16061627</artwork></figure>
    16071628<t>
    1608    If multiple encodings have been applied to a representation, the transfer-codings
    1609    &MUST; be listed in the order in which they were applied.
     1629   If more than one Transfer-Encoding header field is present in a message,
     1630   the multiple field-values &MUST; be combined into one field-value,
     1631   according to the algorithm defined in <xref target="header.fields"/>,
     1632   before determining the message-body length.
     1633</t>
     1634<t>
     1635   Unlike Content-Encoding (&content-codings;), Transfer-Encoding is a
     1636   property of the message, not of the payload, and thus &MAY; be added or
     1637   removed by any implementation along the request/response chain.
    16101638   Additional information about the encoding parameters &MAY; be provided
    16111639   by other header fields not defined by this specification.
    16121640</t>
    16131641<t>
    1614    Many older HTTP/1.0 applications do not understand the Transfer-Encoding
    1615    header field.
    1616 </t>
    1617 <t>
    1618    If more than one
    1619    Transfer-Encoding header field is present in a message, the multiple
    1620    field-values &MUST; be combined into one field-value, according to the
    1621    algorithm defined in <xref target="header.fields"/>, before determining
    1622    the message-body length.
    1623 </t>
    1624 <t>
    1625    When one or more transfer-codings are applied to a payload in order to
    1626    form the message-body, the Transfer-Encoding header field &MUST; contain
    1627    the list of transfer-codings applied. Transfer-Encoding is a property of
    1628    the message, not of the payload, and thus &MAY; be added or removed by
    1629    any implementation along the request/response chain under the constraints
    1630    found in <xref target="transfer.codings"/>.
     1642   Transfer-Encoding was added in HTTP/1.1.  It is generally assumed that
     1643   implementations advertising only HTTP/1.0 support will not understand
     1644   how to process a transfer-encoded payload.
     1645   A client &MUST-NOT; send a request containing Transfer-Encoding unless it
     1646   knows the server will handle HTTP/1.1 (or later) requests; such knowledge
     1647   might be in the form of specific user configuration or by remembering the
     1648   version of a prior received response.
     1649   A server &MUST-NOT; send a response containing Transfer-Encoding unless
     1650   the corresponding request indicates HTTP/1.1 (or later).
     1651</t>
     1652<t>
     1653   A server that receives a request message with a transfer-coding it does
     1654   not understand &SHOULD; respond with 501 (Not Implemented) and then
     1655   close the connection.
    16311656</t>
    16321657</section>
     
    16881713<section title="Message Body Length" anchor="message.body.length">
    16891714<t>
    1690    The length of the message-body is determined by one of the following
     1715   The length of a message-body is determined by one of the following
    16911716   (in order of precedence):
    16921717</t>
     
    17011726    <x:lt><t>
    17021727     If a Transfer-Encoding header field is present
    1703      and the "chunked" transfer-coding (<xref target="transfer.codings"/>)
     1728     and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
    17041729     is the final encoding, the message-body length is determined by reading
    17051730     and decoding the chunked data until the transfer-coding indicates the
     
    21112136</section>
    21122137
    2113 <section title="Associating Response to Request" anchor="associating.request.response">
     2138<section title="Associating a Response to a Request" anchor="associating.response.to.request">
    21142139<t>
    21152140   HTTP does not include a request identifier for associating a given
     
    21652190   transfer-coding values in the TE header field (<xref target="header.te"/>) and in
    21662191   the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
    2167 </t>
    2168 <t>
    2169    Transfer-codings are analogous to the Content-Transfer-Encoding values of
    2170    MIME, which were designed to enable safe transport of binary data over a
    2171    7-bit transport service (<xref target="RFC2045" x:fmt="," x:sec="6"/>).
    2172    However, safe transport
    2173    has a different focus for an 8bit-clean transfer protocol. In HTTP,
    2174    the only unsafe characteristic of message-bodies is the difficulty in
    2175    determining the exact message body length (<xref target="message.body"/>),
    2176    or the desire to encrypt data over a shared transport.
    2177 </t>
    2178 <t>
    2179    A server that receives a request message with a transfer-coding it does
    2180    not understand &SHOULD; respond with 501 (Not Implemented) and then
    2181    close the connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
    2182    client.
    21832192</t>
    21842193
     
    22912300   Use of chunk-ext extensions by senders is deprecated; they &SHOULD-NOT; be
    22922301   sent and definition of new chunk-extensions is discouraged.
    2293 </t>
    2294 <t>
    2295    Since "chunked" is the only transfer-coding required to be understood
    2296    by HTTP/1.1 recipients, it plays a crucial role in delimiting messages
    2297    on a persistent connection.  Whenever a transfer-coding is applied to
    2298    a payload body in a request, the final transfer-coding applied &MUST;
    2299    be "chunked".  If a transfer-coding is applied to a response payload
    2300    body, then either the final transfer-coding applied &MUST; be "chunked"
    2301    or the message &MUST; be terminated by closing the connection. When the
    2302    "chunked" transfer-coding is used, it &MUST; be the last transfer-coding
    2303    applied to form the message-body. The "chunked" transfer-coding &MUST-NOT;
    2304    be applied more than once in a message-body.
    23052302</t>
    23062303</section>
Note: See TracChangeset for help on using the changeset viewer.