Changeset 2338


Ignore:
Timestamp:
Aug 1, 2013, 6:40:34 PM (6 years ago)
Author:
fielding@…
Message:

(editorial) Explain what trailer fields are and use a better example of what not to place in a trailer

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

Legend:

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

    r2334 r2338  
    16241624      <p id="rfc.section.4.1.1.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that
    16251625         might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing
    1626          status. A sender <em class="bcp14">MUST NOT</em> generate a trailer containing a field that needs to be known before a recipient processes the body, such as <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, and <a href="#header.trailer" class="smpl">Trailer</a>.
     1626         status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message
     1627         header block.
    16271628      </p>
    16281629      <p id="rfc.section.4.1.1.p.2">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in
     
    16321633      </p>
    16331634      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.75"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    1634 </pre><p id="rfc.section.4.1.1.p.4">A server <em class="bcp14">MUST</em> generate an empty trailer with the chunked transfer coding unless at least one of the following is true:
     1635</pre><p id="rfc.section.4.1.1.p.4">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field which needs to be known by the recipient before it can begin processing the message
     1636         body. For example, most recipients need to know the values of <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> and <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> in order to select a content handler, so placing those fields in a trailer would force the recipient to buffer the entire
     1637         body before it could begin, greatly increasing user-perceived latency and defeating one of the main advantages of using chunked
     1638         to send data streams of unknown length. A sender <em class="bcp14">MUST NOT</em> generate a trailer containing a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, or <a href="#header.trailer" class="smpl">Trailer</a> field.
     1639      </p>
     1640      <p id="rfc.section.4.1.1.p.5">A server <em class="bcp14">MUST</em> generate an empty trailer with the chunked transfer coding unless at least one of the following is true:
    16351641      </p>
    16361642      <ol>
     
    16421648         </li>
    16431649      </ol>
    1644       <p id="rfc.section.4.1.1.p.5">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later)
     1650      <p id="rfc.section.4.1.1.p.6">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later)
    16451651         proxy and forwarded to an HTTP/1.0 recipient.
    16461652      </p>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2334 r2338  
    20272027   chunked message in order to supply metadata that might be dynamically
    20282028   generated while the message body is sent, such as a message integrity
    2029    check, digital signature, or post-processing status.
    2030    A sender &MUST-NOT; generate a trailer containing a field that needs to be
    2031    known before a recipient processes the body, such as
    2032    <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, and
    2033    <x:ref>Trailer</x:ref>.
     2029   check, digital signature, or post-processing status. The trailer fields are
     2030   identical to header fields, except they are sent in a chunked trailer
     2031   instead of the message header block.
    20342032</t>
    20352033<t>
     
    20462044  <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>
    20472045</artwork></figure>
     2046<t>
     2047   A sender &MUST-NOT; generate a trailer that contains a field which needs to
     2048   be known by the recipient before it can begin processing the message body.
     2049   For example, most recipients need to know the values of
     2050   <x:ref>Content-Encoding</x:ref> and <x:ref>Content-Type</x:ref> in order to
     2051   select a content handler, so placing those fields in a trailer would force
     2052   the recipient to buffer the entire body before it could begin, greatly
     2053   increasing user-perceived latency and defeating one of the main advantages
     2054   of using chunked to send data streams of unknown length.
     2055   A sender &MUST-NOT; generate a trailer containing a
     2056   <x:ref>Transfer-Encoding</x:ref>,
     2057   <x:ref>Content-Length</x:ref>, or
     2058   <x:ref>Trailer</x:ref> field.
     2059</t>
    20482060<t>
    20492061   A server &MUST; generate an empty trailer with the chunked transfer coding
Note: See TracChangeset for help on using the changeset viewer.