GOAWAY(AND_DONT_COME_BACK)

Assuming that a server is dealing with a buggy client, it seems like a good
idea to have a mechanism that tells the client to GOAWAY, and don't use
this protocol when coming back.

As an example, if a server detects that the client is not responding
correctly to flow control, the server could instruct it to not use HTTP/2
until the client is restarted (or similar).

This is likely not useful in the client->server direction.

I think of this as similar to alternate-protocol, though it should not need
a request to indicate that the protocol should not be reused.

It would be impractical to use this on the client->server direction for a
number of reasons:
1) The server would have to store millions or billions of entries
2) There is no guarantee that a single server is dealing with the client,
even if the client is connecting to one IP
3) A single client should not be able to stop a server from serving HTTP/2
for others.


A big question is:
Is this sufficiently different from PROTOCOL_ERROR that it is needed (I
view that as the why, as opposed to what to do)? If not, should we have
suggestions about appropriate behavior in response to PROTOCOL_ERROR?

In my view, yes and yes. This is important because the server should not be
forced to disable HTTP/2 support for everyone in order to work around a
buggy clients, and because the server cannot have the appropriate
information (IP is not enough in this world of NATs and proxies) to
determine that the client is a bad one. Client version strings could give
some hint... but there is no guarantee that the client version string
announced actually is the client in question.

Speaking from experience, it is far far worse to have a set of clients
which end up in a persistent state of non-connectivity than to have worse
latency. If either side detects that this is happening, then either side
should be able to make this decision.

-=R