Feb 28, 2012, 12:46:03 AM (7 years ago)

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

1 edited


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

    r1549 r1550  
    15861586  <x:anchor-alias value="Transfer-Encoding"/>
    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"/>.
    15941594<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/>
    16191619   the message &MUST; be terminated by closing the connection.
    1621 <t>
    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
     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.
    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.
     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.
    16611673  <x:anchor-alias value="Content-Length"/>
    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.
     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>
     1687   An example is
     1689<figure><artwork type="example">
     1690  Content-Length: 3495
    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.
    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.
     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"/>).
    17071717   field containing that decimal value prior to determining the message body
    17081718   length.
     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.
    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>
Note: See TracChangeset for help on using the changeset viewer.