Re: GOAWAY clarification

Martin Thomson <martin.thomson@gmail.com> Sun, 22 March 2015 15:55 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 39C931AC39C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 22 Mar 2015 08:55:25 -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 hUACzD9Tn3EK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 22 Mar 2015 08:55:23 -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 9E3A61A8A1D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 22 Mar 2015 08:55:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YZiAA-000772-9t for ietf-http-wg-dist@listhub.w3.org; Sun, 22 Mar 2015 15:51:42 +0000
Resent-Date: Sun, 22 Mar 2015 15:51:42 +0000
Resent-Message-Id: <E1YZiAA-000772-9t@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 1YZi9y-00076C-DU for ietf-http-wg@listhub.w3.org; Sun, 22 Mar 2015 15:51:30 +0000
Received: from mail-oi0-f47.google.com ([209.85.218.47]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1YZi9x-0000oJ-Gx for ietf-http-wg@w3.org; Sun, 22 Mar 2015 15:51:30 +0000
Received: by oifl3 with SMTP id l3so93888249oif.0 for <ietf-http-wg@w3.org>; Sun, 22 Mar 2015 08:51:03 -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 :cc:content-type; bh=6fCcC9x5PBTKYhcDJax34qJJwSggOAoUS6wWGZmTzPw=; b=lzIlJ2o92oPKY2A4yHwT3bYj71oPMBV+oAHOBlUXK2nxXqOQoJIqyxMdhq23Obf5OC RxqZz2pXMA9AzfNUbIdzLDuTBK4FnFjn+V2CjUvRJb0OrM+l3vFJeG7XXlX9kiTVKd/p +YhSUX8CXZX58FqXAt7JXDOYq5o5Tz3zfG7v/SjxXmnaK+gEFLwqv1ia5gDDI8XV2eI4 Csyzi8rzMPCkp1EzUg8jS3x8jOYF64S4VVtYv/6ZIkybm8EYmuHw3HY5/dWJHZKXWAD+ FjGd7gGP7iCr+d83dD2f/EJoRNmXmfOhcwb9B7PxZ2iDrWfmMdXbbjnQK2ZSc+FvIOmV fggA==
MIME-Version: 1.0
X-Received: by 10.202.210.215 with SMTP id j206mr39652424oig.131.1427039463448; Sun, 22 Mar 2015 08:51:03 -0700 (PDT)
Received: by 10.202.48.151 with HTTP; Sun, 22 Mar 2015 08:51:03 -0700 (PDT)
In-Reply-To: <CABkgnnUoVZkj6+8cVapJ9gp_OPDgkD_FzrUspK8jJu=vkhV-rA@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>
Date: Sun, 22 Mar 2015 08:51:03 -0700
Message-ID: <CABkgnnWz87Rwrhdc-2N+v+3=uskwavn7QhxZHAZPaAscTRg7xw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.218.47; envelope-from=martin.thomson@gmail.com; helo=mail-oi0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=0.398, 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 1YZi9x-0000oJ-Gx e1ad540b5ad179b0159c9eab6c5f9738
X-Original-To: ietf-http-wg@w3.org
Subject: Re: GOAWAY clarification
Archived-At: <http://www.w3.org/mid/CABkgnnWz87Rwrhdc-2N+v+3=uskwavn7QhxZHAZPaAscTRg7xw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29008
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>

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.