Re: Design: Ignored Unknown Frame Types and Intermediaries

Yoav Nir <ynir@checkpoint.com> Tue, 14 May 2013 14:39 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA1121F8653 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 07:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.166
X-Spam-Level:
X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a89ETsPH+VuF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 07:39:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 28D5421F8263 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 14 May 2013 07:38:58 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UcGMI-0002vw-DY for ietf-http-wg-dist@listhub.w3.org; Tue, 14 May 2013 14:37:42 +0000
Resent-Date: Tue, 14 May 2013 14:37:42 +0000
Resent-Message-Id: <E1UcGMI-0002vw-DY@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ynir@checkpoint.com>) id 1UcGM6-0002qy-LI for ietf-http-wg@listhub.w3.org; Tue, 14 May 2013 14:37:30 +0000
Received: from smtp.checkpoint.com ([194.29.34.68]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <ynir@checkpoint.com>) id 1UcGLz-0000f7-NM for ietf-http-wg@w3.org; Tue, 14 May 2013 14:37:30 +0000
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r4EEanH3011617; Tue, 14 May 2013 17:36:49 +0300
X-CheckPoint: {51924A1A-1D-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Tue, 14 May 2013 17:36:49 +0300
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.141]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 1183611970620d3ab9d1566aa88fb5727753dad460
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
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=-0.611, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.629
X-W3C-Scan-Sig: lisa.w3.org 1UcGLz-0000f7-NM fa54899ceba7686fb969340465c55155
X-Original-To: ietf-http-wg@w3.org
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
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17989
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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)
> 
> It's hard to tell if an extension may be safely ignored at the protocol level.  Would there be any use in having a "critical extension" bit, indicating an extension frame that must not be silently dropped by intermediaries or ignored by the destination server?
> 

I don't know. If you send a critical extension to an old(*) server, it's going 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. 

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 resetting the stream (which goes against the design goal of such proxies to be as transparent 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 changed its behavior because of that ignored frame.

So you could have two bits, one as your described, and the other for whether an intermediary can ignore it (similar to the ranges of types that James suggested). But that assumes that whoever designs these extensions knows about 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 SETTINGS 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 the start, I can see Roberto's point that we might as well negotiate it in version strings.

Yoav

(*) "old" means a server conforming to the base HTTP/2.0 specification