RE: GOAWAY(AND_DONT_COME_BACK)

That last is the piece that concerns me, personally.  If a client is departing from the spec badly enough that you don't want to do HTTP/2 with it anymore, why would you have any confidence that it would obey the spec by correctly implementing AND_DONT_COME_BACK?

From: Roberto Peon [mailto:fenix@google.com]
Sent: Tuesday, June 18, 2013 3:39 PM
To: Martin Thomson
Cc: ietf-http-wg@w3.org Group
Subject: Re: GOAWAY(AND_DONT_COME_BACK)

inline

On Tue, Jun 18, 2013 at 3:32 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On 18 June 2013 15:23, Roberto Peon <fenix@google.com<mailto:fenix@google.com>> wrote:
> 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, this is very much in the same bucket as the proposed
COME_BACK code.  The motivation is basically sound.  Both require that
a client observe a particular GOAWAY code and amend their behavior for
a subsequent connection to the server.  Both require that we set
expectations around the scope of the guidance, both in time and the
servers that are affected.

Personally, I don't see a good incentive for a client implementation
to add this feature.  However, I can understand why a client might
choose to implement COME_BACK, even though the incentives aren't
exactly clear there either.  Once you have COME_BACK, this might be a
less onerous addition to a client implementation.  Maybe.  I'd like to
hear from people building clients as to how hard they believe that
this would be to implement.

The incentive is that "X works on Firefox but not Chrome", (or vice versa, etc).
X could be Google, Facebook, whatever.

This kind of failure makes the client look bad, it makes the site look bad. Both are incented to fix it (though the site is more incented to fix it, generally), but fixing it often requires action on the part of the user.
What if the user doesn't have permissions to change the client, or simply can't be bothered to do so?

I don't want to be in a situation where sites don't deploy HTTP/2 because of buggy clients.
Certainly there would be clients which would not implement this, or do it in a broken way.

-=R