Subject: [quicwg/base-drafts] Move GOAWAY to HTTP draft (#696)

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Jul 2017 11:46:10 -0700

We've discussed doing this multiple times, but I can't find an issue on it.  Opening one; if I missed an obvious duplicate, feel free to resolve.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/696

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Jul 2017 11:52:45 -0700

Open question:  Can application-layer GOAWAY be used to signal errors, or is that reserved for the transport-level mechanisms?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/696#issuecomment-318148238

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Jul 2017 01:21:28 +0000 (UTC)

Also, we should link this to #61, since this is part of that cluster.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/696#issuecomment-318229491

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Jul 2017 01:20:33 +0000 (UTC)

First, I think that this is the right design, but we should probably take it to the list for wider input.

However, I've been thinking that our basic design for GOAWAY is flawed.  The design in transport was generic and basically useless for several reasons (I can go into why).  The point of this design is to create a demarcation line, either setting a limit to transactions, or cancellation of any transactions that are already initiated.

The transaction in HTTP/2 is a request.  A request spawns a response and zero or more server pushes.  Once again, the current design uses stream identifiers as a proxy for this and that design works from one perspective, but not the other.

If the server sends GOAWAY, it sets a limit to client streams.  That limits or cancels requests and that works perfectly.

If a client sends GOAWAY, limiting server streams doesn't work.  All this does is prevent the completion of open transactions by curtailing pushes (and responses as well if you accept the premise of unidirectional streams).

I think that the GOAWAY frame needs to identify *requests*, not streams.  Using a stream identifier as a proxy for that is fine, but it needs to be a client-initiated stream.  Then clients can commit to not making any more requests, but servers are not unduly limited in how they respond to those requests.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/696#issuecomment-318229355

---

From: Mike Bishop <[email-masked]>
Date: Thu, 27 Jul 2017 16:49:47 +0000 (UTC)

That's part of why the text refers to prohibiting requests -- I've removed the "respond to GOAWAY with GOAWAY" requirement and the send-before-closing requirements, and am turning it in the direction of a server-to-client-only frame.  If the client wants to close the connection, it just stops making new requests.  (And possibly RST_STREAM / DISINTEREST on anything where incoming pushes are still possible.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/696#issuecomment-318420565