Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
We previously debated whether the Transport should send GOAWAY frames on shutdown, but couldn't think of a useful reason why.
The spec does say:
Or code is like:
// TODO: do clients send GOAWAY too? maybe? Just Close: cc.tconn.Close()
But I'm still not quite sure why a server would care.
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.