Re: GOAWAY clarification

Martin Thomson <> Sat, 21 March 2015 16:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D8E2C1A016C for <>; Sat, 21 Mar 2015 09:40:22 -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 XuaMhilBr8hD for <>; Sat, 21 Mar 2015 09:40:20 -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 593181A01F9 for <>; Sat, 21 Mar 2015 09:40:19 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YZMNr-0002Xc-RW for; Sat, 21 Mar 2015 16:36:23 +0000
Resent-Date: Sat, 21 Mar 2015 16:36:23 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YZMNg-0002W2-Ct for; Sat, 21 Mar 2015 16:36:12 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1YZMNf-0001bb-8Z for; Sat, 21 Mar 2015 16:36:12 +0000
Received: by obcjt1 with SMTP id jt1so77264140obc.2 for <>; Sat, 21 Mar 2015 09:35:45 -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=Aygqeult6S6ZezUXGP4yhmZnTftzBIzegQiWqFBTNn4=; b=H/wZ3pzp1MG9SBsqPmZsXCMpyOoBiq2IVahD48IvkD+jkiCIsZtRQt6xcVQNm+pvig i7TGIMHJl2MFJ2pkNjEv7QXmYdo1klhUHUT1uwiwU9Jps3WuH0uGfYk1J4dmSvqFqXvU GPSUdQFvFm56k+uggB6UJE0z7s2Y6jf8Cx5KzsEnwi7QKuiSrhuH8fp0xB0ZXPA1lVOT pphfmgoZtCBNTcor9aEbuqMgCB4P3PbQWiJNtjhaJZkwUmlf5axQJ/L9lw5E/+eARW3x 8aiXnloVrljgVtLR+B/T1sK07AWSGSAGZBeAlqr3o8xUA008t0SOtLJyXAE9O1GzDrVY IaHQ==
MIME-Version: 1.0
X-Received: by with SMTP id mw5mr70392335obc.26.1426955745538; Sat, 21 Mar 2015 09:35:45 -0700 (PDT)
Received: by with HTTP; Sat, 21 Mar 2015 09:35:45 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sat, 21 Mar 2015 09:35:45 -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: 1YZMNf-0001bb-8Z 639d8f032f87981d099ce52288c0d0cd
Subject: Re: GOAWAY clarification
Archived-At: <>
X-Mailing-List: <> archive/latest/29005
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.

On 21 March 2015 at 00:12, Amos Jeffries <> wrote:
> 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?
> Amos