Re: Question about H2 and chunked encoding

Hi Roy,

On Tue, Sep 26, 2017 at 04:26:39PM -0700, Roy T. Fielding wrote:
> The existing requirements are in
> http://httpwg.org/specs/rfc7230.html#rfc.section.4.1.2
> 
>   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 [RFC7231]), authentication (e.g., see [RFC7235] and [RFC6265]),
>   response control data (e.g., see Section 7.1 of [RFC7231]), 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.
> 
> 
> You suggested adding two normative requirements to message processing,
> both based on "their definitions".  The first isn't targeted but translates
> into MUST NOT send (instead of the existing MUST NOT generate).  The second
> is a recipient MUST ignore based on *other* definitions.  Both impact
> message processing by intermediaries.
> 
> If we want to add a table to the registry that indicates what header
> fields are forbidden to be in trailers, we can do that without impacting
> the existing text in 7230 (which is carefully worded to avoid being a
> message processing requirement).

In fact I think the root cause of this permanent difficulty is that we
all know that some header fields are used to influence message parsing
and framing while others are related to content definition, which used
to be called entity-header fields in 2616. But by considering all of
them as header fields without a strict distinction, we're seeing some
exceptions like above appear. I tend to think that the wording in 7230
using "e.g." in the list is exactly what makes it hard for implementations
to establish a strict list, and that it might be useful to draw such a
list of the fields affecting message parsing and framing, those affecting
message routing/acceptance (host,cookie/set-cookie,auth,cache-control,...)
and maybe other classes, and establish a matrix of which ones are allowed
where. For example for H2 we have a strict list of the fields that must be
discarded during H1 to H2 translation, that makes it easier to implement.

Just my 2 cents,
Willy

Received on Wednesday, 27 September 2017 03:05:34 UTC