HTTP/QUIC GOAWAY when there is no client request?

Lucas Pardue <> Mon, 05 March 2018 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 504DC12D778 for <>; Mon, 5 Mar 2018 04:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k0W3mmDnTJxs for <>; Mon, 5 Mar 2018 04:20:21 -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 BF532124207 for <>; Mon, 5 Mar 2018 04:20:20 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2) with ESMTP id w25CKJEm026462 for <>; Mon, 5 Mar 2018 12:20:19 GMT
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Mon, 5 Mar 2018 12:20:19 +0000
From: Lucas Pardue <>
Subject: HTTP/QUIC GOAWAY when there is no client request?
Thread-Topic: HTTP/QUIC GOAWAY when there is no client request?
Thread-Index: AdO0ejjEIYl/lHjWRr238wQqrZNEsg==
Date: Mon, 5 Mar 2018 12:20:17 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAE6341@bgb01xud1012>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--18.250300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAE6341bgb01xud1012_"
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 12:20:22 -0000


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?