Re: GOAWAY(AND_DONT_COME_BACK)

I don't, but it improves the chances.

The complexity level of implementing the other parts of the spec correctly
is significantly higher than getting this part right.
Do I know we need it? No. I have seen situations where it would have
helped, as we have interacted with buggy clients and were faced with the
decision of turning off SPDY for all of Google. This was a poor position to
be in.
-=R


On Tue, Jun 18, 2013 at 4:21 PM, Mike Bishop
<Michael.Bishop@microsoft.com>wrote:

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