Re: Design: Ignored Unknown Frame Types and Intermediaries

Roberto Peon <> Tue, 14 May 2013 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BA9121F8470 for <>; Tue, 14 May 2013 11:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SL92bFUJ18W5 for <>; Tue, 14 May 2013 11:08:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D845821F90B3 for <>; Tue, 14 May 2013 11:08:51 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UcJdC-0000AX-Rz for; Tue, 14 May 2013 18:07:22 +0000
Resent-Date: Tue, 14 May 2013 18:07:22 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UcJcz-00008I-Tf for; Tue, 14 May 2013 18:07:09 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UcJcy-0000by-GK for; Tue, 14 May 2013 18:07:09 +0000
Received: by with SMTP id m1so1015319oag.20 for <>; Tue, 14 May 2013 11:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HJybN5YDXEIBw8xdmNHt26Z8XEogOora8EO2yOC/Q4c=; b=FQHppJN9/fuwP7jtapHbnpUTVCny6eACOmJDe0QQjMeRFtbQe18k+lFNiSOTIeqUks TnJAYiDAgt/Xm3NQib4pnvDDaYt54eNIAJ4zp+9S1O0Mk0VKyWchuKfVyCOC/L0oQnLV B1avzJlsk1TwKUEbhvP/9flzi0OYZQR0d9wqkBnHfAuqX6aOtpCIYzfqxPKKua50YeBZ c70XJj34+Iq4TIjLlzgHc45+xhf+LBv/lphpknlSDLMmOT/t62tTPXCgfhIesUKdDA8C y//DDei08t9DjNKY74DhBDP4585RGsPbZLAvwQhmzIPGTpS9wgkIGcGZD1aZyqexfHLn dlHw==
MIME-Version: 1.0
X-Received: by with SMTP id t6mr17365319oem.121.1368554802589; Tue, 14 May 2013 11:06:42 -0700 (PDT)
Received: by with HTTP; Tue, 14 May 2013 11:06:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 14 May 2013 11:06:42 -0700
Message-ID: <>
From: Roberto Peon <>
To: Yoav Nir <>
Cc: Albert Lunde <>, "" <>
Content-Type: multipart/alternative; boundary="089e01494972dd3b8304dcb17e98"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.689, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UcJcy-0000by-GK eb03b0eab9dc31059457061ac0c8b100
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <>
X-Mailing-List: <> archive/latest/17991
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


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 <> wrote:

> 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.
> Yoav
> (*) "old" means a server conforming to the base HTTP/2.0 specification