Re: GOAWAY(AND_DONT_COME_BACK)

No objection here for A), but I've seen cases where I already know that B
is insufficient to prevent pain. The question is, is that pain enough to
warrant this additional complexity.
I assume we'll know more after people have implemented the first draft or
two, and an happy to defer until then.

-=R


On Tue, Jun 18, 2013 at 5:37 PM, James M Snell <jasnell@gmail.com> wrote:

> Understood. I propose we defer this proposal until: A) the initial
> implementation draft is complete and B) it's proven that
> PROTOCOL_ERROR is not going to be sufficient.
>
> On Tue, Jun 18, 2013 at 5:28 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > I admit I'm much less worried about clients which don't persisting the
> > connection, unlike browsers which may attempt to reuse the connection,
> and
> > which do significantly more fate-sharing.
> > -=R
> >
> >
> > On Tue, Jun 18, 2013 at 5:12 PM, James M Snell <jasnell@gmail.com>
> wrote:
> >>
> >> +1... for what it's worth, I'm definitely -1 on introducing a "don't
> >> come back" error code. As a generic REST client implementer
> >> (non-browser) I would never have any real motivation for implementing
> >> it and no real idea how I would implement it reliably. It does not buy
> >> us anything more than PROTOCOL_ERROR and would be unreliable at best.
> >> Further, there's no effective way to enforce the "don't come back"
> >> part. This is the internet, anyone can send anything they want, pretty
> >> much any time they want. That's a double edged sword, of course, but
> >> that's just the way it works.
> >>
> >> COMEBACK, at the very least, serves a very distinct and simple purpose
> >> (for those on the list who were not at the interim and may not be
> >> familiar with the idea yet, the COMEBACK code has been proposed (by me
> >> in response to Roberto's DDOS prevention use case) as a means of
> >> telling a client that the connection is being disconnected and that
> >> the client should reconnect using the last known SETTINGS. Whether and
> >> how to reconnect is still left up to the client. Implementation of the
> >> COMEBACK code would be very simple and straightforward.
> >>
> >>
> >>
> >> 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
> >> >
> >> >
> >> >
> >> >
> >>
> >
>