RE: HTTP/QUIC GOAWAY when there is no client request?

Lucas Pardue <> Mon, 05 March 2018 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48A9F12D7E4 for <>; Mon, 5 Mar 2018 11:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OlOGRw_iEy5r for <>; Mon, 5 Mar 2018 11:36:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00AEF124BAC for <>; Mon, 5 Mar 2018 11:36:21 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2) with ESMTP id w25JaGRO001023; Mon, 5 Mar 2018 19:36:16 GMT
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Mon, 5 Mar 2018 19:36:16 +0000
From: Lucas Pardue <>
To: Mike Bishop <>, IETF QUIC WG <>
Subject: RE: HTTP/QUIC GOAWAY when there is no client request?
Thread-Topic: HTTP/QUIC GOAWAY when there is no client request?
Thread-Index: AdO0ejjEIYl/lHjWRr238wQqrZNEsgANUOXQAAJd+BM=
Date: Mon, 5 Mar 2018 19:36:15 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAE644A@bgb01xud1012>
References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE6341@bgb01xud1012>, <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-originating-ip: []
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--19.882600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAE644Abgb01xud1012_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Mar 2018 19:36:24 -0000

I tend to agree, the GOAWAY frame is only using the identifer, not the actual stream. So using 0 here would not violate any rule.

I just wonder if implementors of HTTP/QUIC might be minded to make stream 0 a no-go identifier as a blanket rule, there are not many other places I've seen that would require it's usage.

From: Mike Bishop []
Sent: 05 March 2018 18:28
To: Lucas Pardue; IETF QUIC WG
Subject: RE: HTTP/QUIC GOAWAY when there is no client request?

Stream 0 still seems appropriate.  It meets the requirements, and indicates that the last request accepted was no request.  The error code text is a hangover – I’ll address that.

From: QUIC [] On Behalf Of Lucas Pardue
Sent: Monday, March 5, 2018 4:20 AM
Subject: HTTP/QUIC GOAWAY when there is no client request?


Reading section 4.2.7 of draft-ietf-quic-http-09, it says:

   The GOAWAY frame does not define any flags, and the payload is a QUIC
   Stream ID for a client-initiated, bidirectional stream encoded as a
   variable-length integer.

Steam 0 is the first client-initiated, bidirectional stream. However, it is reserved for the transport’s cryptographic operations.

So how would you handle a client that opens a connection but delays sending requests (for some reason)?



While I’m here, section 4.2.7 later says:

   An endpoint MAY send multiple GOAWAY frames if circumstances change.

   For instance, an endpoint that sends GOAWAY without an error code

   during graceful shutdown could subsequently encounter an error


Is this reference to “an error code” supposed to be in relation to CONNECTION_CLOSE or APPLICATION_CLOSE, or is it a hangover from some older version of GOAWAY?