Re: Design: Ignored Unknown Frame Types and Intermediaries

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 14:37:30 UTC