Re: Question about H2 and chunked encoding

> 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:
>>> 
>>>> On 4 Aug 2017, at 8:15 pm, Cory Benfield <cory@lukasa.co.uk> wrote:
>>>> 
>>>>> On 4 Aug 2017, at 08:43, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>>>>> 
>>>>> The live, so far, in my test cases for Apache httpd. I'd expect them to get used when the web starts worrying about message integrity more, once the https everywhere thing is done. ;-)
>>>> 
>>>> Adding to the list, HTTP/1.1 trailers are barely supported in the Python ecosystem: none of the major libraries or tools can emit them, and many fail to parse them. The better implementations parse-but-ignore. The Python HTTP/2 stack supports emitting and parsing trailers.
>>> 
>>> 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.

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

....Roy

Received on Tuesday, 26 September 2017 23:27:04 UTC