Re: Design: Ignored Unknown Frame Types and Intermediaries

Yoav--

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.

-=R




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
>