Re: GOAWAY(AND_DONT_COME_BACK)

s/persisting/persist/
*sigh*
-=R


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