W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: h2 header field names

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 4 Sep 2014 08:37:02 +0200
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20140904063702.GG7732@1wt.eu>
On Wed, Sep 03, 2014 at 12:36:12PM -0700, Martin Thomson wrote:
> I think that this might be more substantial, so I'm going to confirm
> my choices here before proceeding.
> 
> On 31 August 2014 19:37, Roy T. Fielding <fielding@gbiv.com> wrote:
> > HTTP/2 allows header field names that are not valid header fields in
> > the Internet Message Syntax used by HTTP/1.1 and cannot be registered
> > as such with IANA.  An intermediary that is attempting to translate an
> > HTTP/2 request or response containing such an invalid field name into
> > an HTTP/1.1 message ought to ...
> 
> I'm currently thinking that the correct choice is to treat the request
> or response as malformed
> (http://http2.github.io/http2-spec/#malformed), which would force a
> request or response to be treated as an error and dropped or ignored.

I agree. In fact I'm thinking that if we slice the gatewaying process into
multiple stages, we'd see :
  - HTTP/2 demux
  - HPACK decoding
  - HTTP/1 message emission
  - HTTP/1 parsing

The last step would result in a 400/badreq or whatever variations implementors
decide upon. If we simplify the stages, we can imagine a number of things
including closing the stream during decoding if the decoding stage is
dedicated to 2->1 conversion only here.

So I think that indeed we must mandate that 2->1 gateways actively reject
messages that cannot be emitted over HTTP/1 according to the spec.

Willy
Received on Thursday, 4 September 2014 06:37:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC