Re: Design: Ignored Unknown Frame Types and Intermediaries

Yoav Nir <> Sun, 12 May 2013 05:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 523B321F8501 for <>; Sat, 11 May 2013 22:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.475
X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EGIlipS2KpRD for <>; Sat, 11 May 2013 22:00:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ACD3E21F850B for <>; Sat, 11 May 2013 22:00:51 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UbON1-0001sT-6x for; Sun, 12 May 2013 04:58:51 +0000
Resent-Date: Sun, 12 May 2013 04:58:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UbOMk-0001rf-Al for; Sun, 12 May 2013 04:58:34 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UbOMi-0003G3-B7 for; Sun, 12 May 2013 04:58:34 +0000
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r4C4w3vu010457; Sun, 12 May 2013 07:58:03 +0300
X-CheckPoint: {518F1F94-0-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Sun, 12 May 2013 07:58:03 +0300
From: Yoav Nir <>
To: James M Snell <>
CC: "" <>
Thread-Topic: Design: Ignored Unknown Frame Types and Intermediaries
Thread-Index: AQHOTlx/8z1i47QzLki5Jx/qYX4EwpkAy5cA
Date: Sun, 12 May 2013 04:58:02 +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: 110bc87e31c8d4a8c92fba93fa0144af7abefaf5e1
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: permerror client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: AWL=-0.122, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.45
X-W3C-Scan-Sig: 1UbOMi-0003G3-B7 05b0e5852b9491fc7daed9c38da93ebf
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <>
X-Mailing-List: <> archive/latest/17952
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.