Re: #551: recipient handling of trailer fields

WFM


On Thu, Jan 30, 2014 at 6:25 PM, Mark Nottingham <mnot@mnot.net> wrote:

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