Re: GOAWAY(AND_DONT_COME_BACK)

inline


On Tue, Jun 18, 2013 at 3:32 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 18 June 2013 15:23, Roberto Peon <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