Re: GOAWAY clarification

Martin Thomson <> Sun, 22 March 2015 15:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 39C931AC39C for <>; Sun, 22 Mar 2015 08:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.012
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hUACzD9Tn3EK for <>; Sun, 22 Mar 2015 08:55:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E3A61A8A1D for <>; Sun, 22 Mar 2015 08:55:23 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YZiAA-000772-9t for; Sun, 22 Mar 2015 15:51:42 +0000
Resent-Date: Sun, 22 Mar 2015 15:51:42 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YZi9y-00076C-DU for; Sun, 22 Mar 2015 15:51:30 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1YZi9x-0000oJ-Gx for; Sun, 22 Mar 2015 15:51:30 +0000
Received: by oifl3 with SMTP id l3so93888249oif.0 for <>; Sun, 22 Mar 2015 08:51:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id j206mr39652424oig.131.1427039463448; Sun, 22 Mar 2015 08:51:03 -0700 (PDT)
Received: by with HTTP; Sun, 22 Mar 2015 08:51:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 22 Mar 2015 08:51:03 -0700
Message-ID: <>
From: Martin Thomson <>
To: Amos Jeffries <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
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: 1YZi9x-0000oJ-Gx e1ad540b5ad179b0159c9eab6c5f9738
Subject: Re: GOAWAY clarification
Archived-At: <>
X-Mailing-List: <> archive/latest/29008
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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:

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 <> wrote:
> On 21 March 2015 at 09:35, Martin Thomson <> 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.
> 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.