#551: recipient handling of trailer fields

In response to a Richard Barnes (IESG) comment on p1:

  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/551

I have made some changes to the requirements around sending and
processing received trailer fields.  A complete diff is at

  http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2580

but the important design bits are in p1 4.1.2 (Chunked Trailer Part):

OLD:
   A sender MUST NOT generate a trailer that contains a field which
   needs to be known by the recipient before it can begin processing the
   message body.  For example, most recipients need to know the values
   of Content-Encoding and Content-Type in order to select a content
   handler, so placing those fields in a trailer would force the
   recipient to buffer the entire body before it could begin, greatly
   increasing user-perceived latency and defeating one of the main
   advantages of using chunked to send data streams of unknown length.
   A sender MUST NOT generate a trailer containing a Transfer-Encoding,
   Content-Length, or Trailer field.

   A server MUST generate an empty trailer with the chunked transfer
   coding unless at least one of the following is true:

   1.  the request included a TE header field that indicates "trailers"
       is acceptable in the transfer coding of the response, as
       described in Section 4.3; or,

   2.  the trailer fields consist entirely of optional metadata and the
       recipient could use the message (in a manner acceptable to the
       generating server) without receiving that metadata.  In other
       words, the generating server is willing to accept the possibility
       that the trailer fields might be silently discarded along the
       path to the client.

   The above requirement prevents the need for an infinite buffer when a
   message is being received by an HTTP/1.1 (or later) proxy and
   forwarded to an HTTP/1.0 recipient.

NEW:
   A sender MUST NOT generate a trailer that contains a field necessary
   for message framing (e.g., Transfer-Encoding and Content-Length),
   routing (e.g., Host), request modifiers (e.g., controls and
   conditionals in Section 5 of [Part2]), authentication (e.g., see
   [Part7] and [RFC6265]), response control data (e.g., see Section 7.1
   of [Part2]), or determining how to process the payload (e.g.,
   Content-Encoding, Content-Type, Content-Range, and Trailer).

   When a chunked message containing a non-empty trailer is received,
   the recipient MAY process the fields (aside from those forbidden
   above) as if they were appended to the message's header section.  A
   recipient MUST ignore (or consider as an error) any fields that are
   forbidden to be sent in a trailer, since processing them as if they
   were present in the header section might bypass external security
   filters.

   Unless the request includes a TE header field indicating "trailers"
   is acceptable, as described in Section 4.3, a server SHOULD NOT
   generate trailer fields that it believes are necessary for the user
   agent to receive.  Without a TE containing "trailers", the server
   ought to assume that the trailer fields might be silently discarded
   along the path to the user agent.  This requirement allows
   intermediaries to forward a de-chunked message to an HTTP/1.0
   recipient without buffering the entire response.


and in the pseudo-code of 4.1.3 (Decoding Chunked):

OLD:
     read header-field
     while (header-field not empty) {
        append header-field to existing header fields
        read header-field
     }

NEW:
     read trailer field
     while (trailer field is not empty) {
        if trailer field is allowed to be sent in a trailer,
            append trailer field to existing header fields
        read trailer-field
     }


Please let us know if there are any problems with these changes.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>

Received on Friday, 24 January 2014 22:33:10 UTC