Re: Design: Ignored Unknown Frame Types and Intermediaries

James M Snell <jasnell@gmail.com> Mon, 13 May 2013 04:26 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 B649221F8454 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 12 May 2013 21:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 36dvre8vds0m for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 12 May 2013 21:26:45 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDA121F8E3C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 12 May 2013 21:26:45 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UbkL5-0006Ot-BE for ietf-http-wg-dist@listhub.w3.org; Mon, 13 May 2013 04:26:19 +0000
Resent-Date: Mon, 13 May 2013 04:26:19 +0000
Resent-Message-Id: <E1UbkL5-0006Ot-BE@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UbkKu-0006NM-R0 for ietf-http-wg@listhub.w3.org; Mon, 13 May 2013 04:26:08 +0000
Received: from mail-oa0-f45.google.com ([209.85.219.45]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UbkKt-0008NH-MK for ietf-http-wg@w3.org; Mon, 13 May 2013 04:26:08 +0000
Received: by mail-oa0-f45.google.com with SMTP id j6so6002364oag.18 for <ietf-http-wg@w3.org>; Sun, 12 May 2013 21:25:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pb/6uZ/mIimn91ZLHSqoi3UufXtbx8BsgMNHCGQotx0=; b=ACOp3fdrjmOkjWfgmHz0ZpOhYh5UQ5Yj8sNdjp6HN27nIN6YL/E1SMb4lfyx/qCpZ2 8QOkrQTmFxobPiEsTivBd+hZ/uD3OCtvHlD6GSDE+U2FUX8G0vTep33+4q6Lj83rNuCw JXwgA/9DdRdc8Rn37KIdntZYhfrXQGnQwC3FQEFiwqP8aZKXHPOPQDhQATwrl/puFjon vkIPq07+dA+4hlBCV5QezBqtdv9zpirssW8KaYLmNCS3e87+mfWY+iiy8E02GybU0wxV fn3yid7byQyFM34Mhuq5FZYXryJyv6mrJE208zaQX3Dq+2XHdGE10Koo2jTvKxenh1Gl 3O3A==
X-Received: by 10.182.129.4 with SMTP id ns4mr1917883obb.22.1368419141777; Sun, 12 May 2013 21:25:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Sun, 12 May 2013 21:25:21 -0700 (PDT)
In-Reply-To: <CAP+FsNe2L2aZbDhM4OiWmh7b7f0HkrVfGwa6aKkD2ohNNKJHxg@mail.gmail.com>
References: <CABP7Rbfko48A0yAceDeHfQKR7S6aW7AAAqCZroaZzTScTooOvw@mail.gmail.com> <09C78900-966B-46B0-AB97-1394FD05849A@checkpoint.com> <CAP+FsNe2L2aZbDhM4OiWmh7b7f0HkrVfGwa6aKkD2ohNNKJHxg@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Sun, 12 May 2013 21:25:21 -0700
Message-ID: <CABP7RbexuWR+Hoah8VOTz7Vcuj1zh0Niwiq08tmufdjBtqV0_g@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Yoav Nir <ynir@checkpoint.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.219.45; envelope-from=jasnell@gmail.com; helo=mail-oa0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.692, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UbkKt-0008NH-MK 422e905a4e19ddfc35a1a66a76e56e6f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <http://www.w3.org/mid/CABP7RbexuWR+Hoah8VOTz7Vcuj1zh0Niwiq08tmufdjBtqV0_g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17961
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>

-1. "ignore it" is not a sufficient answer to ensure interoperability
on the new extension points being defined. This needs to be tightened
up.

On Sun, May 12, 2013 at 11:15 AM, Roberto Peon <grmocg@gmail.com> 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.
> -=R
>
>
> On Sat, May 11, 2013 at 9:58 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>>
>>
>> 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.
>> >
>> > 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.
>>
>> Yoav
>
>