Re: GOAWAY clarification

Amos Jeffries <> Sat, 21 March 2015 07:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B9E41A90F5 for <>; Sat, 21 Mar 2015 00:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CCInKCNbbNwb for <>; Sat, 21 Mar 2015 00:16:25 -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 A17631A8938 for <>; Sat, 21 Mar 2015 00:16:25 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YZDav-00019j-Pv for; Sat, 21 Mar 2015 07:13:17 +0000
Resent-Date: Sat, 21 Mar 2015 07:13:17 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YZDao-00015s-J5 for; Sat, 21 Mar 2015 07:13:10 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1YZDan-0007ZJ-AC for; Sat, 21 Mar 2015 07:13:10 +0000
Received: from [] ( []) by (Postfix) with ESMTP id 33B1DE6FBD for <>; Sat, 21 Mar 2015 19:12:36 +1200 (NZST)
Message-ID: <>
Date: Sat, 21 Mar 2015 20:12:27 +1300
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.418, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1YZDan-0007ZJ-AC 2dd16e4fb53cad5566d0c63e8572ddb5
Subject: Re: GOAWAY clarification
Archived-At: <>
X-Mailing-List: <> archive/latest/29003
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 21/03/2015 6:53 p.m., Martin Thomson wrote:
> This seems right to me...
> @
> ---
> We are working on a HTTP/2 library and we are a bit confused and we
> would like to get it right. That's why I am kindly asking for you to
> answer the following question:
> Is it correct that after a sender sent a GOAWAY frame with some last
> stream identifier to a receiver, the sender may still open new
> streams, even with stream identifiers higher than the last stream
> identifier sent in the GOAWAY frame? That is the GOAWAY frame and the
> last stream identifier only limit the ability of the receiver?
> If this is correct, and I believe it is, then the I find the following
> sentence in the first paragraph at 6.8 GOAWAY confusing.
>     Once sent, the sender will ignore frames sent on any new streams
> with identifiers higher than the included last stream identifier.

Translation: "go away, Im ignoring *all* future streams after N"

> In my opinion it should say something of the like
>     Once sent, the sender will ignore frames sent on any new streams
> created by the receiver with identifiers higher than the included last
> stream identifier.

Translation: "I am going to ignore you now while I continue making new
streams to fill your pipe ..."

The behaviour is very different and IMHO the proposal allows senders to
violate the intent of the GOAWAY.

> Thank you very much!
> ---
> After all, the purpose is to create a synchronization point for
> streams created by a peer, marking some set of them as safe to retry.
> There is little value in delineating streams created by the sender of

Yes, however one must take into account what type of action the
synchronisation was done for / is signalling.

Its pretty clear that the intent of the GOAWAY is to signal connection
closure gracefully. There is no sense in starting new streams after
having told the other end you are about to *terminate the connection*.

> That has some ramifications, that I'm sure everyone is already aware
> of: a server that has decided to process a client frame might
> reasonably initiate server push after sending GOAWAY.  Equally, a
> client might hang around after GOAWAY and even make more requests, but
> server pushes would be "ignored".

Currently its a "might" not "must".

If the proposed alteration happens it becomes a must, because until the
sender of GOAWAY actually completes sending the last possible stream-ID
from the full set of 2^32-1, the recipient of GOAWAY cant be sure its
not going to try sending "just one more".

> Of course, given that interpretation GOAWAY from a client could be
> seen as equivalent to SETTINGS_ENABLE_PUSH=0, depending on the value
> of the last stream ID provided, that is.
> I'm not sure that these are new ramifications.  The question is
> whether we want to somehow prevent any aspect of this interpretation.
> At this extremely late stage in the process that would require
> something extraordinary, but I offer the opportunity nonetheless.

If a PUSH_PROMISE was sent *before* sending GOAWAY, then the sender is
free to complete it under the existing semantics.

If it was sent *after* the GOAWAY then the remote end is already in the
process of discarding state and terminating the connection. There is no
guarantee that any of it will be handled, so why would a sane sender
bother wasting bandwidth on new streams it can expect to be dropped?