Re: Design Issue: Must Ignore Rule for Unknown Frame Types

William Chan (陈智昌) <willchan@chromium.org> Fri, 26 April 2013 04:58 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 85BB421F8EF7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 21:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 As0fthD-WwkH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 21:58:34 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 30B1221F8E46 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Apr 2013 21:58:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVaif-0001KF-1H for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Apr 2013 04:57:13 +0000
Resent-Date: Fri, 26 Apr 2013 04:57:13 +0000
Resent-Message-Id: <E1UVaif-0001KF-1H@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UVaiW-0001JV-W8 for ietf-http-wg@listhub.w3.org; Fri, 26 Apr 2013 04:57:05 +0000
Received: from mail-qc0-f179.google.com ([209.85.216.179]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UVaiW-0001X4-2d for ietf-http-wg@w3.org; Fri, 26 Apr 2013 04:57:04 +0000
Received: by mail-qc0-f179.google.com with SMTP id v28so1816018qcm.24 for <ietf-http-wg@w3.org>; Thu, 25 Apr 2013 21:56:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EdAnOU9zgMZU7grrENrKglt8NnGi1Mj7MTtMQUgAeFM=; b=ioKjmcOiO/7QXBY7JjhqEXe/dLGQo6SKEyhqVEaBK94xySSfl70u6bC99prJ8uBufb 0V5gnExfg3w1DH2To7uaFMpm5fVAcIaKg6chml0OEaVPiA6dugrQEdozLeu0VC/mW4iw 1h3LYDNnIUnChsu9EPj0055s60NB/pBukoThz6OQTBjd++COikUWCHFb3Rfa+2VSyXhQ uDTJKS2EbzkW2eKvgV1ehuEsD9ZxSSZ13kn4yzMEiYFag5gSoEOQHTbGcsOgD8zi0I9M 5+GwnWtLbLWkI0OQv8y7v7Sf+ed9pAapjawr0Lk32SN2klT0JFhPsZCfZ5lfMcMfaKpX VVZg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EdAnOU9zgMZU7grrENrKglt8NnGi1Mj7MTtMQUgAeFM=; b=gE7ym5fblNYNer8c5zuBcTFZVKbbkIfbZ7orlgxmN91b7tyB9Qy0sNIUwUx2A8ARLd k8nyXgNCNaKdzyibAJqx9LAkuM0ZDBH0IwYkeSJaCCAo1eiNybcno0fOHuAxM2xNaSCa 07gBuCV060aXPgZakyb39KW+2O1qBOcKX2l74=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=EdAnOU9zgMZU7grrENrKglt8NnGi1Mj7MTtMQUgAeFM=; b=ijaLSXFlD4NJ0/5RJcTEFE/B4AW2fMMomoCpxRGlo3Lilio2HEdv2W9KjuEnXV1C60 9X/ScB9cqHV6eC+Qbk+f5n38P1+krW0V37XwJ/Y/zcpjJysU8ltxZHODHnPLV2PSbFx8 J8bEfMJQGTKmgs9ruXrOlpCtUFxNRr+yRJ6zjH1Dle0zWPrZwymFCfxaOMqUqN+VUnDF GhEpA70VLI9lyfvmqd7rRhhEUBHsW+64nCJEsdnjCFkvHWN1pwZaZcR3rPquSJzBKYGq 1uQW1WJgAWxYCwCHSjDg6PywaXXhaF6X7t7y+7irDMvVAB0fBLeaT+5qb0visHB6nw4p 0r9Q==
MIME-Version: 1.0
X-Received: by 10.224.210.10 with SMTP id gi10mr13580340qab.36.1366952198419; Thu, 25 Apr 2013 21:56:38 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Thu, 25 Apr 2013 21:56:38 -0700 (PDT)
In-Reply-To: <CABP7RbfWkhh=ziOyOzTf5ahQBYNe=JdGXCy9ERR_9DpE8tdWZQ@mail.gmail.com>
References: <CABP7Rbe_wEayjZnkMhLpexaKqYUaP7dP-bvAr8PK3bvjueV_rw@mail.gmail.com> <CABkgnnWCCC23=6hQJAhicdihSaDdcc79xHbKB8ntiyKvY6XE5w@mail.gmail.com> <CABP7RbfWkhh=ziOyOzTf5ahQBYNe=JdGXCy9ERR_9DpE8tdWZQ@mail.gmail.com>
Date: Thu, 25 Apr 2013 21:56:38 -0700
X-Google-Sender-Auth: GmmrqEZyjTPgPLxcEm_D9sRPqd0
Message-ID: <CAA4WUYhNRxVbwuqScNazj8=1YBCdAoEmR=6cwD6ddrYAsLrcfw@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=20cf300faeed3653f104db3c5c5a
X-Gm-Message-State: ALoCoQndfaMAegxC9998gfln/vyQqC/KQTPvDELk12iJ/j1uuy6wky9M0DE1bUkylxMlXMINxjDVwHjKLttjkTK9UfDU/srNgQHpkOLUQmty/ziEqnuh1q3rUnOQQ6mMg0uuoTazzHYGCsiBv0dFuT3azbthG0JniWAaJQqsZcYP/WBZyUOArUpCQEv71lT595PXz5lnKXHJ
Received-SPF: pass client-ip=209.85.216.179; envelope-from=willchan@google.com; helo=mail-qc0-f179.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.729, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UVaiW-0001X4-2d 6be9a232adc18b8a790fb7582e045762
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Must Ignore Rule for Unknown Frame Types
Archived-At: <http://www.w3.org/mid/CAA4WUYhNRxVbwuqScNazj8=1YBCdAoEmR=6cwD6ddrYAsLrcfw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17595
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>

I think this is a good clarification.


On Thu, Apr 25, 2013 at 4:20 PM, James M Snell <jasnell@gmail.com> wrote:

> Ok, then if we go with MUST Ignore, we need to be explicit about
> requiring that unknown frame types cannot modify session / connection
> state. The most significant effect of this is that new frame types
> must not contain compressed header blocks that utilize the same shared
> compression state as known frames. That does not rule out the use of
> header compression in those frames, it just dictates that the state
> management for those occur at a higher level in the stack.
>
> On Thu, Apr 25, 2013 at 4:14 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > If "MUST ignore", then it follows that "cannot modify session/connection
> state".
> >
> > I prefer "MUST ignore" because it allows for new frame types within a
> > standardized negotiated protocol without fatal errors.  If you want to
> > have new frame types modify session state, then you can negotiate a
> > new protocol (HTTP/2.infinity)".
> >
> > BTW, that's a standard response we came up with informally at the
> > Tokyo interim.  If someone wants to break the protocol, they are free
> > to break their own because negotiating new protocols is going to be
> > easy ... we hope.
> >
> > On 25 April 2013 15:58, James M Snell <jasnell@gmail.com> wrote:
> >> https://github.com/http2/http2-spec/issues/80
> >>
> >> In the current draft (-02) we say, "Implementations MUST ignore
> >> unsupported and unrecognized frame types." but we give no guidance
> >> that I can find about handling unknown frames that potentially modify
> >> session state. For example, suppose some extension comes up with a new
> >> frame type that includes a compressed header block. The receiving
> >> endpoint will have no way of interpreting the content, but if it
> >> ignores the frame entirely, it's stored session state can unknowingly
> >> fall out of sync with the sender.
> >>
> >> Recommendation: rather than a "MUST IGNORE" rule here, unknown and
> >> unrecognized frame types ought to be a Session Error because the
> >> receiver cannot determine whether and how those frames may have
> >> changed the session state on the sending side. It would not be safe
> >> for the receiver to continue attempting to communicate with the sender
> >> on that session.
> >>
> >> This obviously has an impact on the extensibility of the framing
> >> layer. In short, a sender would not be able to use a new frame type
> >> unless it knows the receiver can interpret it. The only solution for
> >> that would be to have some kind of negotiation occur where the sender
> >> effectively ask the recipient if particular extensions are supported
> >> (as part of the session header perhaps?)
> >>
>
>