Re: Question about H2 and chunked encoding

On 27 Sep 2017, at 9:26 am, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
>> On Sep 25, 2017, at 9:01 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>>> On 26 Sep 2017, at 6:52 am, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> 
>>>> On Aug 6, 2017, at 8:26 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>>> 
>>>> This thread makes me wonder if we can't improve things slightly in HTTPtre. E.g., we could say:
>>>> 
>>>>> A header field MUST NOT appear in trailers unless its definition allows it. Receiving implementations MUST ignore header fields appearing in trailers when their definitions do not allow it.
>>>> 
>>>> ... with an appropriate column in the header field registry to record this. I don't think this would break any existing implementations, because trailers are so seldom used right now, and I think there's a strong argument that this is the case anyway; the consuming application has to expect something in trailers to act upon it.
>>>> 
>>>> <https://github.com/httpwg/http11bis/issues/16#issuecomment-320513541>
>>> 
>>> We spent an enormous amount of time separating HTTP message processing from required understanding of its semantics.  What you describe above is not an improvement.  It isn't even implementable, in general.
>> 
>> This has nothing to do with message processing.

[...]

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

The intent was to affect the processing of the header field's semantics, not generic message handling. As noted in <https://github.com/httpwg/http11bis/issues/16#issuecomment-320587821>, it's not really possible to do it as part of message processing.

The problem we're trying to address is that right now, any header (barring those that explicitly prohibit it) can be sent as a trailer, and potentially upgraded to a header by an intermediary on the path or the receiving endpoint. If the header isn't designed for this, it can be surprising in an unpleasant way, which is one of the reasons browser security people get antsy about trailers.

If we invert permissions so that the default is that nothing can go in trailers unless it's explicitly allowed by definition, I think it's much closer to the reality of deployment now; that unless a header explicitly nominates itself for use in trailers, it's not going to work there.

Note that I'm not suggesting that we require generic message processors to enforce this (although they're free to try, of course, e.g., in Web Application Firewalls). What I am suggesting is that when someone generates a trailer, they do so only when the header definition allows it, and when someone consumes a trailer, likewise the definition had better allow it. 

We also should remove the language saying that trailers are "identical" and "processed as if they were appended to the message's header section", when clearly they're different.

While we're at it, we should probably at least discourage implementations from moving trailers into the headers, or presenting trailers as headers. I know that historically this may have happened, but I don't *think* it's the case with much modern software.

Cheers,


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

Received on Friday, 29 September 2017 07:06:34 UTC