Re: GOAWAY clarification

Martin Thomson <martin.thomson@gmail.com> Sun, 22 March 2015 16:23 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAD21A0389 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 22 Mar 2015 09:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Level:
X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGzCC5nwo1EE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 22 Mar 2015 09:23:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE421AC3CA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 22 Mar 2015 09:23:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YZibE-00050v-42 for ietf-http-wg-dist@listhub.w3.org; Sun, 22 Mar 2015 16:19:40 +0000
Resent-Date: Sun, 22 Mar 2015 16:19:40 +0000
Resent-Message-Id: <E1YZibE-00050v-42@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1YZib7-00050A-Kw for ietf-http-wg@listhub.w3.org; Sun, 22 Mar 2015 16:19:33 +0000
Received: from mail-ob0-f169.google.com ([209.85.214.169]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1YZib6-0001e5-PX for ietf-http-wg@w3.org; Sun, 22 Mar 2015 16:19:33 +0000
Received: by obbgg8 with SMTP id gg8so107951154obb.1 for <ietf-http-wg@w3.org>; Sun, 22 Mar 2015 09:19:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7KpTl7Ig0JmByGaLyzjXL0Dqe+Z2HbXAiItSVbUUIdU=; b=sQkRGf+w3ejb/pFUms+x0eLa76vko0b6hjTU3iF3fb4udCBiiEEvq1+XA0OEDNbBGu w8jFM8TQ9OULLL4wNF1dcyaa/tLH65NDznOKRdl3g8K7j6g544Dj4pWOZw3GJJOe8mMA b9V7i499w0StGUqVuA3swL23qe25pTvjDJOsuWtsRMukKfd/BJZJHZJSM3egZx7CohRD NlW40Efq/NPBp2ZDL47P0hCb6246YqtNus745lZsY7jNlRnorP2BpB49dMrW6Je8fQIk EDQeSoNJHAbxOOCzkmoYEdcEb5tcwaivaPPSO6BU3rT9r8ZFDHgs5Z9LDzS//s5vt3eU sw4A==
MIME-Version: 1.0
X-Received: by 10.182.20.237 with SMTP id q13mr52023289obe.82.1427041147119; Sun, 22 Mar 2015 09:19:07 -0700 (PDT)
Received: by 10.202.48.151 with HTTP; Sun, 22 Mar 2015 09:19:07 -0700 (PDT)
In-Reply-To: <CABkgnnWz87Rwrhdc-2N+v+3=uskwavn7QhxZHAZPaAscTRg7xw@mail.gmail.com>
References: <CABkgnnWrZpNjLnQ2mn0YnoU-e1oArWVDmBTqiX=cDAeeA+ZZ+Q@mail.gmail.com> <550D19DB.80306@treenet.co.nz> <CABkgnnXg1uV9AP-fgsMzRyY_71ke31sYYknV+TYbJhiEf1qY0Q@mail.gmail.com> <CABkgnnUoVZkj6+8cVapJ9gp_OPDgkD_FzrUspK8jJu=vkhV-rA@mail.gmail.com> <CABkgnnWz87Rwrhdc-2N+v+3=uskwavn7QhxZHAZPaAscTRg7xw@mail.gmail.com>
Date: Sun, 22 Mar 2015 09:19:07 -0700
Message-ID: <CABkgnnWQaFMnA9AR5v1n6s+x0=UdhRu2j9KmiQoOjhvgQNkvzA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.214.169; envelope-from=martin.thomson@gmail.com; helo=mail-ob0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=0.397, 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, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1YZib6-0001e5-PX 858a6781c4def16c7faf6db9a300bdaa
X-Original-To: ietf-http-wg@w3.org
Subject: Re: GOAWAY clarification
Archived-At: <http://www.w3.org/mid/CABkgnnWQaFMnA9AR5v1n6s+x0=UdhRu2j9KmiQoOjhvgQNkvzA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29009
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>

...and I've drawn some pictures:
https://docs.google.com/presentation/d/1yGLlIUqwVy3WeVv8K9HHOSkBietWTjJPlI_pA5wqU-Q/edit?usp=sharing

On consideration, this is a technical change, albeit one that arises
out of clarifying what was previously ambiguous.  I will take the
advice of the working group on how to proceed.

On 22 March 2015 at 08:51, Martin Thomson <martin.thomson@gmail.com> wrote:
> After sleeping on it, I have taken a more thorough look at the section
> and noted a few other inconsistencies.  Thus, I've made a second
> proposal that is a little more thorough:
>
> https://github.com/http2/http2-spec/pull/733
>
> One note regarding this text, since this has already come up on github...
>
> This shouldn't change behaviour.  If you have an implementation that
> sends GOAWAY based on the stream identifiers you have seen, then you
> are exposed to the "bug" in issue #458, but are otherwise unaffected.
> If you implemented the graceful shutdown based on the text produced
> for #458; that is, you send two GOAWAY frames, then the only
> consequence is that streams might have to be retried by the client.
> Ultimately, the choice of last-stream-id will determine how much
> allowance is made for imminent transactions.
>
> On 21 March 2015 at 19:27, Martin Thomson <martin.thomson@gmail.com> wrote:
>> On 21 March 2015 at 09:35, Martin Thomson <martin.thomson@gmail.com> wrote:
>>> It would be easy to deal with your concern by having the receiver of
>>> the GOAWAY reply with their own.  I think that avoids all of the
>>> problems you indicate.
>>
>>
>> So @Scottmitch also notes a further bug here.  We currently prohibit
>> the creation of more streams after GOAWAY, which is in direct
>> contradiction to the graceful shutdown process.
>>
>>     Receivers of a GOAWAY frame MUST NOT open additional
>>     streams on the connection, although a new connection can be
>>     established for new streams.
>>
>> That contradicts the guidance we provide later in the section
>> regarding graceful shutdown.  It prevents a seamless transition from
>> one connection to another.
>>
>>
>> I've created a PR for this.  https://github.com/http2/http2-spec/pull/732
>>
>> I've also taken the liberty of taking a variation on the text from @buchgr.
>>
>> I think that this is erratum-worthy, so I'd like to get this in.  But
>> I won't do so if there are objections.  If my answer to Amos'
>> objection didn't satisfy you (see above; see also the PR text; Amos?)
>> then I can remove the second part of the change, but I tend to think
>> that it's more consistent with the other fix.