Resent-Date: Tue, 14 May 2013 14:37:42 +0000
Resent-Message-Id: <E1UcGMI-0002vw-DY@frink.w3.org>
From: Yoav Nir <ynir@checkpoint.com>
To: Albert Lunde <atlunde@panix.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/qYX4EwpkAy5cAgADeoYCAAKa9AIAABPcAgADs9oCAACuRgIAAD0gAgAAHqACAAAsDgIAAr7AAgABBxICAABAvAA==
Date: Tue, 14 May 2013 14:36:49 +0000
Message-ID: <61600C9F-6871-4FA0-A0E7-D3F31D408E78@checkpoint.com>
References: <CABP7Rbfko48A0yAceDeHfQKR7S6aW7AAAqCZroaZzTScTooOvw@mail.gmail.com>
 <09C78900-966B-46B0-AB97-1394FD05849A@checkpoint.com>
 <CAP+FsNe2L2aZbDhM4OiWmh7b7f0HkrVfGwa6aKkD2ohNNKJHxg@mail.gmail.com>
 <2124BAB0-8FF1-4D6D-BBD8-F042B1EA5F7B@checkpoint.com>
 <CABP7Rbf+H=WarqFaV0UM5On-3FkYAspkC4OBzh1HE6EpQow94w@mail.gmail.com>
 <CAP+FsNd3260xnQG8JU3UQkkSwaVhVgwkDPPcR02W_W0q12+HFw@mail.gmail.com>
 <CABkgnnXJRHu_LsD+Fq9dTNi9Sqfmj0GQMBGO9QzZy6DCfxSJAQ@mail.gmail.com>
 <CAP+FsNdoZNOV2JxHgVHorp94QC0+KGOrYpVdi5FoZ8jAEsGd5g@mail.gmail.com>
 <CABP7Rbck4xCib9py+AqUHY=SgCoGz+Jw5-yLjzCFhQ_RbpLJQg@mail.gmail.com>
 <CAP+FsNcGYVwM3n3Vcttw-H8a3_vCrG5ysH-mTODBhFyioXcK6Q@mail.gmail.com>
 <DC5B5985-D15C-47EA-90B0-5AABF540BC04@checkpoint.com>
 <51923E87.9040505@panix.com>
In-Reply-To: <51923E87.9040505@panix.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <D99BFD5C0AD0E7408414A6FEEE5757F4@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/61600C9F-6871-4FA0-A0E7-D3F31D408E78@checkpoint.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

On May 14, 2013, at 4:39 PM, Albert Lunde <atlunde@panix.com> 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)
>=20
> It's hard to tell if an extension may be safely ignored at the protocol l=
evel.  Would there be any use in having a "critical extension" bit, indicat=
ing an extension frame that must not be silently dropped by intermediaries =
or ignored by the destination server?
>=20

I don't know. If you send a critical extension to an old(*) server, it's go=
ing 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.=20

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 resettin=
g the stream (which goes against the design goal of such proxies to be as t=
ransparent 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 cha=
nged its behavior because of that ignored frame.

So you could have two bits, one as your described, and the other for whethe=
r an intermediary can ignore it (similar to the ranges of types that James =
suggested). But that assumes that whoever designs these extensions knows ab=
out 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 SETTI=
NGS 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 t=
he start, I can see Roberto's point that we might as well negotiate it in v=
ersion strings.

Yoav

(*) "old" means a server conforming to the base HTTP/2.0 specification=