- From: Daniel Sommermann <dcsommer@fb.com>
- Date: Mon, 21 Apr 2014 17:18:40 -0700
- 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: > 2x MAX_CONCURRENT_STREAMS, I hope. 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 while. 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