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