Re: GOAWAY(AND_DONT_COME_BACK)

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

Received on Wednesday, 19 June 2013 00:13:34 UTC