Re: Design: Ignored Unknown Frame Types and Intermediaries

Yoav Nir <> Mon, 13 May 2013 04:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 663C821F896B for <>; Sun, 12 May 2013 21:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qlx7SHRpex+1 for <>; Sun, 12 May 2013 21:14:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AAE6321F885A for <>; Sun, 12 May 2013 21:13:59 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Ubk7a-0000CS-HP for; Mon, 13 May 2013 04:12:22 +0000
Resent-Date: Mon, 13 May 2013 04:12:22 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ubk7K-0000Bi-H4 for; Mon, 13 May 2013 04:12:06 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ubk7J-00068C-5f for; Mon, 13 May 2013 04:12:06 +0000
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r4D4Basd004379; Mon, 13 May 2013 07:11:36 +0300
X-CheckPoint: {51906624-0-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Mon, 13 May 2013 07:11:36 +0300
From: Yoav Nir <>
To: Roberto Peon <>
CC: James M Snell <>, "" <>
Thread-Topic: Design: Ignored Unknown Frame Types and Intermediaries
Thread-Index: AQHOTlx/8z1i47QzLki5Jx/qYX4EwpkAy5cAgADeoYCAAKa9AA==
Date: Mon, 13 May 2013 04:11:35 +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: 11edba36b4a7560994ba2dd23df7c176f28d315682
Content-Type: multipart/alternative; boundary="_000_2124BAB08FF14D6DBBD8F042B1EA5F7Bcheckpointcom_"
MIME-Version: 1.0
Received-SPF: permerror client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=-0.520, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.628
X-W3C-Scan-Sig: 1Ubk7J-00068C-5f f50c6cdf8d416079763c2747c0e5ac40
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <>
X-Mailing-List: <> archive/latest/17960
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

That's fine for interoperability. And I believe that middleware such as caching proxies or reverse proxies will simply ignore unrecognized frames and pass them on.

Firewalls will either remove the unknown frames or reset the entire connection, and they'll do so regardless of what the spec says. I think that we should have text that says that middleware MAY remove frames not specified in the base draft. The reason is that otherwise the only choice is to reset the entire connection, which makes extending the protocol almost impossible - you'll get into the unhappy place TLS is with "retry at TLS1.0 without extensions, and if that doesn't work go to SSL3", except it's worse for HTTP because the unknown frame could happen at any point during the connection.


On May 12, 2013, at 9:15 PM, Roberto Peon <<>> wrote:

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.


Email secured by Check Point