Is this client side, server side or both?

Client. The server already sends GOAWAY on shutdown and the client already respects the server's GOAWAY so it can retry requests on new connections.

This issue is about whether there's any reason for the client to send GOAWAY when it's closed.

Hm. GOAWAY is roughly "Don't initiate any more streams."

In vanilla H2, the only practical protocol-visible application of a client->server GOAWAY would be to stop the server initiating any more pushes, I think. However, protocol extensions or other ALPN tokens might change that.

Inside the implementation, I suppose it would also give the server an opportunity to release resources in a slightly more ordered fashion (depending on how you close the transport connection).

So, it's polite, and it's a SHOULD in the spec (it says "endpoints," not just "servers"). What are the downsides of sending it?

Anything to add, @martinthomson?

That about sums it up. Though I would add that if a server is tracking whether individual requests are getting through, GOAWAY helps with that. The server never really had any certainty here, but I am aware of cases where there are optimizations that apply when you know that a client had gotten the message.

Decision: let's send it. But not targeting any particular release. If somebody wants to send the change we can review it.