W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: can h2 extension frames carry data?

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 3 Nov 2015 07:36:23 +0100
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20151103063623.GA19965@1wt.eu>
On Tue, Nov 03, 2015 at 02:52:47PM +1000, Matthew Kerwin wrote:
> > Sending extension frames without explicitly knowing the peer can accept
> > them is *your* implementation being broken. At the very least it will be
> > wasting bandwidth and time. At worst it will be screwing up
> > transactions. Neither is good.
> >
> >
> ???"???Implementations MUST ignore unknown or unsupported values in all
> extensible protocol elements.  Implementations MUST discard frames
> that have unknown or unsupported types.  This means that any of these
> extension points can be safely used by extensions without prior
> arrangement or negotiation." RFC 7540, Section 5.5.
> 
> So while it could be a buggy implementation's fault, it could also be that
> the extension was just written that way. I can send some inconsequential
> but interesting ???frame* whenever I like, and according to RFC 7540 that's
> fine; but the proposed RST_STREAM means some recipients might throw an
> error back at me. So I say again, for an error to work it should be baked
> into h2 itself. Here and now, the horse has already bolted.

Strangely that reminds me a discussion we had on this exact subject
a long time ago when discussion the protocol extensibility. Yes in
theory there is a problem with how the protocol is defined, because
in order to respect the protocol and the obligations that are put on
every actor, you'd need to send your compressed data *in addition* to
the clear data so that those who don't understand compression can
silently drop compressed frames and use the other ones. Obviously
that doesn't make sense.

I think we should classify extension frame types in two categories :
  - the ones that can silently be ignored ;
  - the ones that must be understood and that depend on the extension
    to be correctly understood along the chain (including proxies if
    needed).

This also means that extensions must be classified along these two
categories :
  - those that can be ignored
  - those that may affect the framing or protocol contents and which
    all agents must be careful about (ie if an intermediary doesn't
    know the extension, it must strip it).

Maybe it's not too late to define this classification, implementations
will evolve, you just need to be careful to ensure the fallback for those
not aware of it is nice enough. Typically if we define such classification
and some intermediaries want to inspect contents and are not aware of it,
well... they won't find the data they want in gzipped contents and that's
all. That will give them incentive to implement the classification and/or
support for gzip.

Regards,
Willy
Received on Tuesday, 3 November 2015 06:37:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC