Re: Design: Ignored Unknown Frame Types and Intermediaries

Yoav Nir <> Tue, 14 May 2013 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DA1121F8653 for <>; Tue, 14 May 2013 07:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.166
X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a89ETsPH+VuF for <>; Tue, 14 May 2013 07:39:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 28D5421F8263 for <>; Tue, 14 May 2013 07:38:58 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UcGMI-0002vw-DY for; Tue, 14 May 2013 14:37:42 +0000
Resent-Date: Tue, 14 May 2013 14:37:42 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UcGM6-0002qy-LI for; Tue, 14 May 2013 14:37:30 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UcGLz-0000f7-NM for; Tue, 14 May 2013 14:37:30 +0000
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r4EEanH3011617; Tue, 14 May 2013 17:36:49 +0300
X-CheckPoint: {51924A1A-1D-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Tue, 14 May 2013 17:36:49 +0300
From: Yoav Nir <>
To: Albert Lunde <>
CC: "" <>
Thread-Topic: Design: Ignored Unknown Frame Types and Intermediaries
Date: Tue, 14 May 2013 14:36:49 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 1183611970620d3ab9d1566aa88fb5727753dad460
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: permerror client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=-0.611, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.629
X-W3C-Scan-Sig: 1UcGLz-0000f7-NM fa54899ceba7686fb969340465c55155
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <>
X-Mailing-List: <> archive/latest/17989
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On May 14, 2013, at 4:39 PM, Albert Lunde <> 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.


(*) "old" means a server conforming to the base HTTP/2.0 specification