Re: #551: recipient handling of trailer fields

LGTM. Anyone have a problem with this?


On 25 Jan 2014, at 9:32 am, Roy T. Fielding <fielding@gbiv.com> wrote:

> 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/>
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 31 January 2014 02:26:20 UTC