Re: GOAWAY(AND_DONT_COME_BACK)

On Tue, 18 Jun 2013, Roberto Peon wrote:

> 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.

Let me start by declaring my bias ... symetric protocols as much as
possible. 

I think the client->server case would be more like, GO_AWAY(I REFUSE TO
COME BACK) which would be the client indicating Persistent PROTOCOL_ERROR.
This might result in more informative error logging.

OTOH ... I'm having real difficulty understanding why either side would
declare "don't come back" when the detected issue wasn't severe enough
to reset the connection with a PROTOCOL_ERROR.

> 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
>

Received on Tuesday, 18 June 2013 23:03:39 UTC