W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Design: Ignored Unknown Frame Types and Intermediaries

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 14 May 2013 11:06:42 -0700
Message-ID: <CAP+FsNfiuSdrDcTPsKJQxcayaB8mYh6aGAtN19EW+PgTFhmZsw@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: Albert Lunde <atlunde@panix.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>

I think of it even more simply than you describe in your example.
We have standards-conformant versions of HTTP/2, which are well known.
Then we have variations on these versions, which will have different
identifying names, but at a minimum we'd have one *known* version,
HTTP/2.0-experimental. Any server/proxy/client which allows that version to
be negotiated is making a promise to pass along frames it doesn't recognize
without modification.

Later, perhaps some extensions become widely known and useful. At that
point someone helpfully assigns a version of HTTP/2-0-pre-1, which now is
expected to mean HTTP/2 plus whatever extensions. If we continue to do our
job, assuming there is wide acceptance of those extensions, we'll get those
extensions spec'd and get that version documented.


On Tue, May 14, 2013 at 7:36 AM, Yoav Nir <ynir@checkpoint.com> wrote:

> On May 14, 2013, at 4:39 PM, Albert Lunde <atlunde@panix.com> wrote:
> > On 5/14/2013 4:46 AM, Yoav Nir wrote:
> >> But I agree that we should limit what non-version-changing extensions
> >> are allowed to do. We should require that if the extension is either
> >> ignored by the recipient or removed by a middlebox, no harm would be
> >> done (except the new functionality not working)
> >
> > It's hard to tell if an extension may be safely ignored at the protocol
> level.  Would there be any use in having a "critical extension" bit,
> indicating an extension frame that must not be silently dropped by
> intermediaries or ignored by the destination server?
> >
> I don't know. If you send a critical extension to an old(*) server, it's
> going to reset the stream or the connection. If you send a critical
> extension through an old firewall, it will reset your stream or connection,
> so that the new extension would sometimes work and sometimes won't.
> Any proxy other than a firewall cannot tell whether the critical extension
> is something that should affect it or not. So it has the choice of
> resetting the stream (which goes against the design goal of such proxies to
> be as transparent to the client as possible) or it could forward the frame,
> which is equivalent to ignoring it. There is no way to know if it should
> have changed its behavior because of that ignored frame.
> So you could have two bits, one as your described, and the other for
> whether an intermediary can ignore it (similar to the ranges of types that
> James suggested). But that assumes that whoever designs these extensions
> knows about all the kinds of proxies that exist, and what is relevant for
> them.
> We could have some kind of negotiation on extension capability in the
> SETTINGS frame, and explicitly allow middleware to remove capabilities that
> they don't support to prevent their use. But if we've gone to negotiate it
> at the start, I can see Roberto's point that we might as well negotiate it
> in version strings.
> Yoav
> (*) "old" means a server conforming to the base HTTP/2.0 specification
Received on Tuesday, 14 May 2013 18:07:10 UTC

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