W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: GOAWAY and proxies (#458)

From: Daniel Sommermann <dcsommer@fb.com>
Date: Mon, 21 Apr 2014 17:18:40 -0700
Message-ID: <5355B560.5070004@fb.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "William Chan (ι™ˆζ™Ίζ˜Œ)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 04/21/2014 04:49 PM, Martin Thomson wrote:
Yeah, I didn't write out the full arithmetic.
> I'm still not clear on why this is insufficient. Can you explain 
> further? (Having text in the spec would still be worthwhile, if that 
> was where we ended up.) 
Acking the extra streams in the GOAWAY is sufficient I think. It's just 
a bit strange, as it implies the remote is committed to servicing 
streams that may never arrive. Normally, GOAWAY is sent very shortly 
before the connection is closed. If the server sends GOAWAY and the 
client stops issuing HTTP requests, the connection could stay open for a 

There are other oddities, like handling the case where a future stream 
causes a second GOAWAY with PROTOCOL_ERROR to be returned (although I 
suppose multiple GOAWAY is already possible today with NO_ERROR and then 
FLOW_CONTROL_ERROR). The second GOAWAY would probably ack a lower number 
than the first in this case.

I'm sure we could add text handling these cases, but I'm worried about 
diluting GOAWAY's current clear semantic meaning with special cases. 
What do others think?
Received on Tuesday, 22 April 2014 00:19:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC