Resent-Date: Sun, 12 May 2013 04:58:51 +0000
Resent-Message-Id: <E1UbON1-0001sT-6x@frink.w3.org>
From: Yoav Nir <ynir@checkpoint.com>
To: James M Snell <jasnell@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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: <09C78900-966B-46B0-AB97-1394FD05849A@checkpoint.com>
References: <CABP7Rbfko48A0yAceDeHfQKR7S6aW7AAAqCZroaZzTScTooOvw@mail.gmail.com>
In-Reply-To: <CABP7Rbfko48A0yAceDeHfQKR7S6aW7AAAqCZroaZzTScTooOvw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B680A68CC1B77E4F892152B6EE34EC00@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: permerror client-ip=194.29.34.68;
 envelope-from=ynir@checkpoint.com; helo=smtp.checkpoint.com
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <http://www.w3.org/mid/09C78900-966B-46B0-AB97-1394FD05849A@checkpoint.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

On May 11, 2013, at 6:27 PM, James M Snell <jasnell@gmail.com> 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.
>=20
> 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...
>=20
> 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
>=20
> 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.
>=20
> - James

I think (C) is the only answer. Consider two types of proxies: an SSL accel=
erator 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 the=
se two kinds of proxy regardless of what we specify.=20

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 tha=
t in the SETTINGS frame, the proxy could filter out.  For example, add a SE=
TTINGS_SUPPORTED_EXTENSION, which will hold an extension supported by the s=
ender. 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=