Re: Design Issue: Merge RST_STREAM and GOAWAY into a single ERROR frame type

William Chan (陈智昌) <willchan@chromium.org> Fri, 03 May 2013 21:46 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 C3ED821F909A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 14:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.026
X-Spam-Level:
X-Spam-Status: No, score=-9.026 tagged_above=-999 required=5 tests=[AWL=0.650, 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 ZntYZyVQN2ua for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 14:45:59 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC5721F907E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 3 May 2013 14:45:59 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UYNnV-0003o2-4G for ietf-http-wg-dist@listhub.w3.org; Fri, 03 May 2013 21:45:45 +0000
Resent-Date: Fri, 03 May 2013 21:45:45 +0000
Resent-Message-Id: <E1UYNnV-0003o2-4G@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 1UYNnK-0003nI-DA for ietf-http-wg@listhub.w3.org; Fri, 03 May 2013 21:45:34 +0000
Received: from mail-qa0-f43.google.com ([209.85.216.43]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UYNnJ-0003oB-AY for ietf-http-wg@w3.org; Fri, 03 May 2013 21:45:34 +0000
Received: by mail-qa0-f43.google.com with SMTP id bs12so589805qab.2 for <ietf-http-wg@w3.org>; Fri, 03 May 2013 14:45:07 -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=3nO1iOlvccc5biDzrjLC6mpTwOAUaoWlq2Zdt4YVMio=; b=K/ShInTqrOLyiN17wtiZqxtB8RCvXBCJOzoK3s1zcyiIEcepn414jlf768dtiVHKal kkSazrARtRclhvloPot5eAgqrOQAn4i0tsy/yyEsm5htvzuWHdAj84n3FEhsI4f+LT4S Zmcq8IehfUIC9mh2blf9QkdwNLO9VrM/gulE76vHDlkVLeu9J9nBJjL/2UxLEdKBTxNl L/4C5FthrFzx7Wog8qlXgABXCzbzsFyOkQIWVTCzWdYkmjWV5rtQqJjvbTSRkRG5/p1c iMffrLelj4qiSiDWpOtYyMVFTape5YBFDYqEmr8r8sLRpJmyrgm2NCdNR32Z1Q9Eoygs 1jwg==
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=3nO1iOlvccc5biDzrjLC6mpTwOAUaoWlq2Zdt4YVMio=; b=n49zG7dXejgppKnjKSVZ9+BAR6dOAN7sII/9uutDh9s0lWaXeLwgQAxS73PnaEjRDF Clwj9pyHdZ5mbKftp9vvZMvHvmlkeNIana8aMS8MWQ4zHVXsgwAlShh4SIeANujhgD5m H67KqFo8A4qkUYdXdXMudeXS+8HcKrzpAS1yI=
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=3nO1iOlvccc5biDzrjLC6mpTwOAUaoWlq2Zdt4YVMio=; b=c6Kku9/KyBvuKiDH9sc/qZdh4Oe3VA7cVvnjqPo2qe+q7Ug+siXGL25nNoe5MzbMVu N7tbC+CWAla7p/n8mCUNgMRG3SW+iflWy73XeHn/W7c6z/NjRi34bgKBGSxYIsvp+fSG wNPGoxKWmRCHPpw+QaRp8lotmXieD51aw6q2J9TzDS1RQL99POG2HGxZHPn1E/u/CaDM DvmhDRz0XEnJ+JyRRoS38GDV4HOrlSPZSDkcBhC/h5xEEzT9OPf2Iq8CMkQIUFP7nCq1 5zF9u5fqBpfnPfYo4Ht5AgJ29P/Zwy6oA2Exb/IRE8wQ6kzCDzbpq8GtIyLIE2dwiQM6 2aAw==
MIME-Version: 1.0
X-Received: by 10.229.113.104 with SMTP id z40mr5292443qcp.20.1367617507086; Fri, 03 May 2013 14:45:07 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Fri, 3 May 2013 14:45:07 -0700 (PDT)
In-Reply-To: <CABP7RbcRP8EvjRd_yLBJtPf9pyhpVTqj-EJYTh23o5rM1J7suA@mail.gmail.com>
References: <CABP7RbeJm-AKxU3qGxt2tCGrb0xCQL8njNyEToA7Ln9gS8hnTQ@mail.gmail.com> <CA+pLO_gWErCMv+j3pcmy+cTkt-hh2v6a7neeyDtg7HRN3x=Sgw@mail.gmail.com> <CABP7RbfJEwkMVum0HXei_mqvJ=pHd2G=jx_wz=sZzboi4ZMwzQ@mail.gmail.com> <CAA4WUYhfup_PM8s7P0PO_EcB8R-O6L32wX-zk73thwBHYHHtgA@mail.gmail.com> <CABP7RbcTbFxNj-qax1An0Qp7okWqvbt5MTXyHZTMn_fBKgx9Fw@mail.gmail.com> <CAA4WUYgYQbD1PmNMqPiQqR++0M7_vf4cWECNxk_i+s9S_kpQKw@mail.gmail.com> <CAP+FsNcN4OyqP=WkmsYUG+m9EHrTuELHx40n7S6wRb6F7L73FQ@mail.gmail.com> <CABP7RbcRP8EvjRd_yLBJtPf9pyhpVTqj-EJYTh23o5rM1J7suA@mail.gmail.com>
Date: Fri, 03 May 2013 18:45:07 -0300
X-Google-Sender-Auth: KHL0njlcz4-pf-RGnTwxwRjY7nA
Message-ID: <CAA4WUYiWTK8upQY0SG0N6xMtXn-+L8bfa91d+j2uXT-gptt37Q@mail.gmail.com>
From: "William Chan (陈智昌)" <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, Jeff Pinner <jpinner@twitter.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001517573c1ab3412004dbd7434c"
X-Gm-Message-State: ALoCoQkA79vYooorBA9GUTnZwRGTrwET3+WpbvUdmNKEDBHaOaJo0BhXFuJwoZ1GGgxpGvDktEk7FFeIHPDOyrGILwL41N8k/ORr++QjMQK/Lm+C1hciO99KP1A+38oP0tWwzKyqKPKfLzR+CeZnlvnvxno/znRApuyMKEbas6+mbuxl5LaMs0YdJ4YqYKp0G9422f1wFp/x
Received-SPF: pass client-ip=209.85.216.43; envelope-from=willchan@google.com; helo=mail-qa0-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-1.387, 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=-2.581, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UYNnJ-0003oB-AY ea1a7bec4082fda050c7080b92c4d584
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Merge RST_STREAM and GOAWAY into a single ERROR frame type
Archived-At: <http://www.w3.org/mid/CAA4WUYiWTK8upQY0SG0N6xMtXn-+L8bfa91d+j2uXT-gptt37Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17823
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>

The lack of non-terminal session errors is reflective of the historical
SPDY developer bias towards hard failure modes, so we don't tolerate
implementation errors that may affect interoperability/correctness later
on. It's opinionated and definitely has its issues.

For "Session frame too big", my inclination would be to terminate the
session. Google Chrome is not tolerant of things it thinks servers should
not be doing :) I think it's been good for the ecosystem overall thus far.
Are there other errors you'd like to see be non-terminal?


On Fri, May 3, 2013 at 6:34 PM, James M Snell <jasnell@gmail.com> wrote:

> Very well.  With that, however, we still have the outstanding ed note...
> How do we want to report non-terminal session errors (e.g.  Session frame
> too big) or do we treat all session errors as terminal using goaway?
> On May 3, 2013 2:25 PM, "Roberto Peon" <grmocg@gmail.com> wrote:
>
>> I also find the current way more obvious-- in wireshark and similar
>> traces, it is far easier to pick out the different opcode type (which is
>> typically rendered as the textual name of the opcode) as opposed to the
>> numeric value in some field.
>>
>> -=R
>>
>>
>> On Fri, May 3, 2013 at 2:12 PM, William Chan (陈智昌) <willchan@chromium.org
>> > wrote:
>>
>>> Sorry, my implication is that I don't see any objective determination of
>>> what's simpler here, just subjective views of which many people can have an
>>> opinion. But if there's consensus on doing this, then by all means, let's
>>> do it. I for one disagree and find the current way simpler :)
>>>
>>>
>>> On Fri, May 3, 2013 at 6:08 PM, James M Snell <jasnell@gmail.com> wrote:
>>>
>>>> There is no bikeshedding going on at all. I made the motivation for
>>>> this clear up front: it's a simplification that addresses three
>>>> specific items. Note: there is an existing editorial note in the
>>>> existing draft that calls out the fact that we have no non-terminal
>>>> method of communicating non-stream related errors. If we can address
>>>> that item while also simplifying things a bit, then fantastic.
>>>>
>>>> On Fri, May 3, 2013 at 2:01 PM, William Chan (陈智昌)
>>>> <willchan@chromium.org> wrote:
>>>> > This is a thread ripe for bikeshedding. Is there any major issue worth
>>>> > solving?
>>>> >
>>>> > If we're going to paint our bike sheds, my take is keep whatever
>>>> color the
>>>> > bike shed already has unless it really offends a number of people.
>>>> >
>>>> >
>>>> > On Fri, May 3, 2013 at 5:53 PM, James M Snell <jasnell@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> Speaking candidly, if we find ourselves requiring more than 8 boolean
>>>> >> flags on an error frame we should all just quit and go home.
>>>> >>
>>>> >> On Fri, May 3, 2013 at 1:34 PM, Jeff Pinner <jpinner@twitter.com>
>>>> wrote:
>>>> >> > IIRC, when this was brought up at the last F2F the rational for NOT
>>>> >> > doing
>>>> >> > this was that frame types were cheaper than flags (256 frame
>>>> types, 8
>>>> >> > flags).
>>>> >> >
>>>> >> > That being said I think we should consider combining them :)
>>>> >> >
>>>> >> >
>>>> >> > On Fri, May 3, 2013 at 1:04 PM, James M Snell <jasnell@gmail.com>
>>>> wrote:
>>>> >> >>
>>>> >> >> As a simplification, I'd like to suggest that we merge the
>>>> RST_STREAM
>>>> >> >> and GOAWAY frames into a single ERROR frame with the following
>>>> >> >> definition:
>>>> >> >>
>>>> >> >>  0                   1                   2                   3
>>>> >> >>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> >> >> |                      Error Code (32)                          |
>>>> >> >> +---------------------------------------------------------------+
>>>> >> >> |X|                  Last-Stream-ID (31)                        |
>>>> >> >> +-+-------------------------------------------------------------+
>>>> >> >>
>>>> >> >> (note that this flips the field order from the GOAWAY frame)
>>>> >> >>
>>>> >> >> A frame-specific GOAWAY flag bit (0x2) would be defined for the
>>>> frame,
>>>> >> >> and the Last-Stream-ID field would only be included in the frame
>>>> data
>>>> >> >> if this flag was set.
>>>> >> >>
>>>> >> >> This does a couple of things for us:
>>>> >> >>
>>>> >> >> 1. It simplifies the error handling and reduces the number of core
>>>> >> >> frame
>>>> >> >> types.
>>>> >> >> 2. It allows us to terminate a stream and terminate the session
>>>> in a
>>>> >> >> single frame if necessary
>>>> >> >> 3. It gives us a way of reporting non-terminal session errors
>>>> >> >> (currently RST_STREAM is forbidden to use stream id #0 and GOAWAY
>>>> is
>>>> >> >> always terminal).
>>>> >> >>
>>>> >> >
>>>> >>
>>>> >
>>>>
>>>
>>>
>>