Re: Question about H2 and chunked encoding

> On Sep 26, 2017, at 8:05 PM, Willy Tarreau <w@1wt.eu> wrote:
> 
> 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.

Well, no, the root cause is that there is no syntactic distinction between
various types of header fields that could be easily seen by all recipients.
That's how we make a protocol self-descriptive.

The problem is that we have no choice in "considering all of them as header
fields without a strict distinction".  That's HTTP/1.  It isn't going to
change by adding requirements to a spec that simply aren't true for HTTP/1.
Even if we required a prefix on names, we'd still have to deal with the
folks who don't read specifications and either fail to use the prefix or
copy the wrong prefix from somewhere else.

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

But, there is no strict list.  That's the point of the e.g.'s.  We can't add
requirements that have no basis in the protocol practice.  I think it is a
fine idea to make distinctions clearer in the registry, but that doesn't
change the normative requirements (how to interoperate).  A strict list is
not going to be interoperable after deployment.

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

*sigh*

....Roy

Received on Wednesday, 27 September 2017 19:30:24 UTC