Re: Design: Ignored Unknown Frame Types and Intermediaries

Roberto Peon <> Sun, 12 May 2013 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD8E221F87C5 for <>; Sun, 12 May 2013 11:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.079
X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z5RHuJTNrP0k for <>; Sun, 12 May 2013 11:17:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 40A5221F8BB7 for <>; Sun, 12 May 2013 11:17:46 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UbaoB-0006gb-3i for; Sun, 12 May 2013 18:15:43 +0000
Resent-Date: Sun, 12 May 2013 18:15:43 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ubanx-0006fn-L0 for; Sun, 12 May 2013 18:15:29 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Ubanv-0006Le-Eu for; Sun, 12 May 2013 18:15:29 +0000
Received: by with SMTP id va2so410363obc.13 for <>; Sun, 12 May 2013 11:15:01 -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=C4oFWvw2iPUn57uIiax0UJnbVO8kiseJdQiME9iOevY=; b=kjkG2WlvljnI7yYEkhmk1MsU/LpEij1L/aJwUTO8yDtohSBGE+3XgtZSBp4m2JYfh5 fyIlvkTcVCqrDOs0MiFCMYROzRcWbDqdH/UPIiNjtlRH65FcOodsVwIIvUoD8hx5x0IA Jv+jX9P4kr/RrPm3ZRJziZvFilP6dmLTMMxm4abZYO5o+TDIN3MRYRVGAxpiwGt6ZbO3 HyKbV0gXKFPD5sbl02Lj991XdWIfZyIQTWP6lI9CDLVqJ4fuIExI0RecnuHSRK7dPi2i Rrph/lZAaBoF0QBNV85cijmF/8tiCGTAyWpN4Joz+4OQLVUYZ4FqqGJrpLSBAKkytwMQ l40Q==
MIME-Version: 1.0
X-Received: by with SMTP id h3mr11238335obm.16.1368382501467; Sun, 12 May 2013 11:15:01 -0700 (PDT)
Received: by with HTTP; Sun, 12 May 2013 11:15:01 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sun, 12 May 2013 11:15:01 -0700
Message-ID: <>
From: Roberto Peon <>
To: Yoav Nir <>
Cc: James M Snell <>, "" <>
Content-Type: multipart/alternative; boundary="001a11c2f402eac10804dc896095"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.688, 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: 1Ubanv-0006Le-Eu 6337c560269f807e84b43bfdfe623d79
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <>
X-Mailing-List: <> archive/latest/17953
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I believe that the simplest thing is that, when you don't understand it,
you ignore it.

If that frame was required at some semantic level, then you should have
rev'd the version number or changed the version string in some other way at
the start of communication. That is easy and robust.

This does imply that changing any state which the baseline protocol of that
version depends upon is a no-no, but doesn't preclude changing state which
the baseline protocol of that version *doesn't* know about.

Making that a MUST, i.e. something like:
And endpoint may use frames with opcodes other than those defined in this
specification, however it MUST NOT do so if ignoring such a frame would
cause an unexpected stream or session error, either directly or indirectly.

On Sat, May 11, 2013 at 9:58 PM, Yoav Nir <> wrote:

> On May 11, 2013, at 6:27 PM, James M Snell <> wrote:
> > In the current draft, endpoints are required to "ignore" unknown and
> > unsupported frame types. What's not yet clear, however, is whether
> > such frames are required to be forwarded on by intermediaries that do
> > not support them.
> >
> > In other words, A talks to C via reverse proxy B. A sends a stream
> > that includes EXTENSION_FRAME_TYPE that is unknown to B. Is B...
> >
> > A) Required to drop the frame silently without forwarding it on to C
> > B) Required to always forward the frame on to C
> > C) Neither, B can do whatever it wants
> >
> > There is an obvious impact here on the future deployment of new
> > extension frame types. If the answer is A or C, we'll have to wait on
> > infrastructure support to use new frame types, which would be
> > unfortunate.
> >
> > - James
> I think (C) is the only answer. Consider two types of proxies: an SSL
> accelerator and a firewall. The SSL accelerator doesn't want to break
> anything, so it will forward everything (B), while a firewall doesn't let
> things pass which it doesn't understand (A). I think this will be the
> behavior for these two kinds of proxy regardless of what we specify.
> Since the UA can never know in advance what the server will support, there
> has to be some "extension support discovery" anyways. Perhaps if we had
> that in the SETTINGS frame, the proxy could filter out.  For example, add a
> SETTINGS_SUPPORTED_EXTENSION, which will hold an extension supported by the
> sender. You will need multiple settings values for multiple extensions. The
> server would send the same list as the client, filtered down to the list of
> extensions that it supports. A proxy could trim the list further to remove
> things it's going to drop.
> Yoav