Re: GOAWAY(AND_DONT_COME_BACK)

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