Ignore:
Timestamp:
Aug 19, 2012, 2:59:58 PM (7 years ago)
Author:
fielding@…
Message:

move Trailer and trailer requirements to one location, inside chunked

File:
1 edited

Legend:

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

    r1831 r1832  
    19121912</artwork></figure>
    19131913<t>
     1914   Chunk extensions within the chucked encoding are deprecated.
     1915   Senders &SHOULD-NOT; send chunk-ext.
     1916   Definition of new chunk extensions is discouraged.
     1917</t>
     1918<t>
    19141919   The chunk-size field is a string of hex digits indicating the size of
    19151920   the chunk-data in octets. The chunked encoding is ended by any chunk whose size is
    19161921   zero, followed by the trailer, which is terminated by an empty line.
    19171922</t>
    1918 <t>
    1919    The trailer allows the sender to include additional HTTP header
    1920    fields at the end of the message. The <x:ref>Trailer</x:ref> header field
    1921    can be used to indicate which header fields are included in a trailer (see
    1922    <xref target="header.trailer"/>).
    1923 </t>
    1924 <t>
    1925    A server using chunked transfer-coding in a response &MUST-NOT; use the
    1926    trailer for any header fields unless at least one of the following is
    1927    true:
     1923
     1924<section title="Trailer" anchor="header.trailer">
     1925  <iref primary="true" item="Trailer header field" x:for-anchor=""/>
     1926  <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/>
     1927  <x:anchor-alias value="Trailer"/>
     1928<t>
     1929   A trailer allows the sender to include additional fields at the end of a
     1930   chunked message in order to supply metadata that might be dynamically
     1931   generated while the message body is sent, such as a message integrity
     1932   check, digital signature, or post-processing status.
     1933   The trailer &MUST-NOT; contain fields that need to be known before a
     1934   recipient processes the body, such as <x:ref>Transfer-Encoding</x:ref>,
     1935   <x:ref>Content-Length</x:ref>, and <x:ref>Trailer</x:ref>.
     1936</t>
     1937<t>
     1938   When a message includes a message body encoded with the chunked
     1939   transfer-coding and the sender desires to send metadata in the form of
     1940   trailer fields at the end of the message, the sender &SHOULD; send a
     1941   <x:ref>Trailer</x:ref> header field before the message body to indicate
     1942   which fields will be present in the trailers. This allows the recipient
     1943   to prepare for receipt of that metadata before it starts processing the body,
     1944   which is useful if the message is being streamed and the recipient wishes
     1945   to confirm an integrity check on the fly.
     1946</t>
     1947<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/>
     1948  <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>
     1949</artwork></figure>
     1950<t>
     1951   If no <x:ref>Trailer</x:ref> header field is present, the sender of a
     1952   chunked message body &SHOULD; send an empty trailer.
     1953</t>
     1954<t>
     1955   A server &MUST; send an empty trailer with the chunked transfer-coding
     1956   unless at least one of the following is true:
    19281957  <list style="numbers">
    19291958    <t>the request included a <x:ref>TE</x:ref> header field that indicates
     
    19311960    described in <xref target="header.te"/>; or,</t>
    19321961     
    1933     <t>the trailer fields consist entirely of optional metadata, and the
     1962    <t>the trailer fields consist entirely of optional metadata and the
    19341963    recipient could use the message (in a manner acceptable to the server where
    1935     the field originated) without receiving it. In other words, the server that
    1936     generated the header field (often but not always the origin server) is
    1937     willing to accept the possibility that the trailer fields might be silently
    1938     discarded along the path to the client.</t>
     1964    the field originated) without receiving that metadata. In other words,
     1965    the server that generated the header field is willing to accept the
     1966    possibility that the trailer fields might be silently discarded along
     1967    the path to the client.</t>
    19391968  </list>
    19401969</t>
    19411970<t>
    1942    This requirement prevents an interoperability failure when the
    1943    message is being received by an HTTP/1.1 (or later) proxy and
    1944    forwarded to an HTTP/1.0 recipient. It avoids a situation where
    1945    conformance with the protocol would have necessitated a possibly
    1946    infinite buffer on the proxy.
    1947 </t>
     1971   The above requirement prevents the need for an infinite buffer when a
     1972   message is being received by an HTTP/1.1 (or later) proxy and forwarded to
     1973   an HTTP/1.0 recipient.
     1974</t>
     1975</section>
     1976
     1977<section title="Decoding chunked" anchor="decoding.chunked">
    19481978<t>
    19491979   A process for decoding the "chunked" transfer-coding
     
    19661996  Content-Length := length
    19671997  Remove "chunked" from Transfer-Encoding
     1998  Remove Trailer from existing header fields
    19681999</artwork></figure>
    19692000<t>
     
    19722003   they do not understand.
    19732004</t>
    1974 <t>
    1975    Use of chunk-ext extensions by senders is deprecated; they &SHOULD-NOT; be
    1976    sent and definition of new chunk-extensions is discouraged.
    1977 </t>
     2005</section>
    19782006</section>
    19792007
     
    20902118   in order to prevent the TE field from being forwarded by intermediaries
    20912119   that do not support its semantics.
    2092 </t>
    2093 </section>
    2094 
    2095 <section title="Trailer" anchor="header.trailer">
    2096   <iref primary="true" item="Trailer header field" x:for-anchor=""/>
    2097   <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/>
    2098   <x:anchor-alias value="Trailer"/>
    2099 <t>
    2100    The "Trailer" header field indicates that the given set of
    2101    header fields is present in the trailer of a message encoded with
    2102    chunked transfer-coding.
    2103 </t>
    2104 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/>
    2105   <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>
    2106 </artwork></figure>
    2107 <t>
    2108    An HTTP/1.1 message &SHOULD; include a Trailer header field in a
    2109    message using chunked transfer-coding with a non-empty trailer. Doing
    2110    so allows the recipient to know which header fields to expect in the
    2111    trailer.
    2112 </t>
    2113 <t>
    2114    If no Trailer header field is present, the trailer &SHOULD-NOT;  include
    2115    any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of
    2116    trailer fields in a "chunked" transfer-coding.
    2117 </t>
    2118 <t>
    2119    Message header fields listed in the Trailer header field &MUST-NOT;
    2120    include the following header fields:
    2121   <list style="symbols">
    2122     <t><x:ref>Transfer-Encoding</x:ref></t>
    2123     <t><x:ref>Content-Length</x:ref></t>
    2124     <t><x:ref>Trailer</x:ref></t>
    2125   </list>
    21262120</t>
    21272121</section>
Note: See TracChangeset for help on using the changeset viewer.