Subject: GOAWAY(AND_DONT_COME_BACK)

From: Roberto Peon <[email-masked]>
Date: Tue, 18 Jun 2013 15:23:41 -0700

Assuming that a server is dealing with a buggy client, it seems like a good
idea to have a mechanism that tells the client to GOAWAY, and don't use
this protocol when coming back.

As an example, if a server detects that the client is not responding
correctly to flow control, the server could instruct it to not use HTTP/2
until the client is restarted (or similar).

This is likely not useful in the client->server direction.

I think of this as similar to alternate-protocol, though it should not need
a request to indicate that the protocol should not be reused.

It would be impractical to use this on the client->server direction for a
number of reasons:
1) The server would have to store millions or billions of entries
2) There is no guarantee that a single server is dealing with the client,
even if the client is connecting to one IP
3) A single client should not be able to stop a server from serving HTTP/2
for others.

A big question is:
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, yes and yes. This is important because the server should not be
forced to disable HTTP/2 support for everyone in order to work around a
buggy clients, and because the server cannot have the appropriate
information (IP is not enough in this world of NATs and proxies) to
determine that the client is a bad one. Client version strings could give
some hint... but there is no guarantee that the client version string
announced actually is the client in question.

Speaking from experience, it is far far worse to have a set of clients
which end up in a persistent state of non-connectivity than to have worse
latency. If either side detects that this is happening, then either side
should be able to make this decision.

-=R

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jun 2013 15:32:42 -0700

On 18 June 2013 15:23, Roberto Peon <[email-masked]> 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

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.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 18 Jun 2013 15:38:34 -0700

inline

On Tue, Jun 18, 2013 at 3:32 PM, Martin Thomson <[email-masked]>wrote:

> view

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

---

From: David Morris <[email-masked]>
Date: Tue, 18 Jun 2013 16:03:10 -0700 (PDT)

> 3) A single client should not be able to stop a server from serving HTTP/2

Let me start by declaring my bias ... symetric protocols as much as
possible. 

I think the client->server case would be more like, GO_AWAY(I REFUSE TO
COME BACK) which would be the client indicating Persistent PROTOCOL_ERROR.
This might result in more informative error logging.

OTOH ... I'm having real difficulty understanding why either side would
declare "don't come back" when the detected issue wasn't severe enough
to reset the connection with a PROTOCOL_ERROR.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 18 Jun 2013 23:21:07 +0000

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:[email-masked]]
Sent: Tuesday, June 18, 2013 3:39 PM
To: Martin Thomson
Cc: [email-masked] Group
Subject: Re: GOAWAY(AND_DONT_COME_BACK)

inline

On Tue, Jun 18, 2013 at 3:32 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Roberto Peon <[email-masked]>
Date: Tue, 18 Jun 2013 16:24:25 -0700

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
<[email-masked]>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:[email-masked]]
> *Sent:* Tuesday, June 18, 2013 3:39 PM
> *To:* Martin Thomson
> *Cc:* [email-masked] Group
> *Subject:* Re: GOAWAY(AND_DONT_COME_BACK)****
>
> ** **
>
> inline****
>
> ** **
>
> On Tue, Jun 18, 2013 at 3:32 PM, Martin Thomson <[email-masked]>
> wrote:****
>
> > suggestions about appropriate behavior in response to PROTOCOL_ERROR?***
> *
>
> this would be to implement.****
>
>  ** **
>
> 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.
> ****
>
> can't be bothered to do so?****
>
> ** **
>
> of buggy clients.****
> in a broken way.****
> ** **
> -=R****
>  ****
> ** **

---

From: James M Snell <[email-masked]>
Date: Tue, 18 Jun 2013 17:12:47 -0700

+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
<[email-masked]> wrote:
> it anymore, why would you have any confidence that it would obey the spec by
> correctly implementing AND_DONT_COME_BACK?
>
>
>
> wrote:

---

From: Roberto Peon <[email-masked]>
Date: Tue, 18 Jun 2013 17:28:42 -0700

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 <[email-masked]> wrote:

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

---

From: James M Snell <[email-masked]>
Date: Tue, 18 Jun 2013 17:37:45 -0700

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.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 18 Jun 2013 17:38:15 -0700

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

---

From: Roberto Peon <[email-masked]>
Date: Tue, 18 Jun 2013 17:40:20 -0700

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 19 Jun 2013 08:20:40 +0000

In message <[email-masked]>, David Morris 

>to reset the connection with a PROTOCOL_ERROR.

Policy decisions ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Jun 2013 10:31:45 +0200

On 6/19/13 12:23 AM, Roberto Peon wrote:
>
> Assuming that a server is dealing with a buggy client, it seems like a
> good idea to have a mechanism that tells the client to GOAWAY, and
> don't use this protocol when coming back.
>

What makes you think an already broken client would handle this
situation correctly?  Worse, if implemented incorrectly by the server,
you end up telling everyone to go away and not come back.  Don't get
that code wrong!!

---

From: Roberto Peon <[email-masked]>
Date: Wed, 19 Jun 2013 09:42:22 -0700

The damage of telling everyone to not use http/2 is that they use http/1.
So, bothersome but not fatal.
The complexity of getting this right is lower than that of getting other
features right.

In any case we'll know more after a couple drafts worth of implementations
have had the experience of deployment.

Until then, who knows if this is a useful tradeoff? :)

-=R
On Jun 19, 2013 1:33 AM, "Eliot Lear" <[email-masked]> wrote:

> good idea to have a mechanism that tells the client to GOAWAY, and don't
> use this protocol when coming back.
>
>
> What makes you think an already broken client would handle this situation
> correctly?  Worse, if implemented incorrectly by the server, you end up
> telling everyone to go away and not come back.  Don't get that code wrong!!
>
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 19 Jun 2013 17:38:43 +0000

In message <CAP+FsNe6Wgso8V-L2xmaptXC01P8OftsH7O3oRjSap=[email-masked]>

>The complexity of getting this right is lower than that of getting other

I should point out that the NTPv4 protocol added a similar facility
in a bid to prevent deluging primary NTP servers with packets from
million-unit-series cheap boxes from taiwanese factories.

The success has been somewhat limited in my opinion, but as the new
NTPD reference code makes its way to various embedded linux variants
more and more boxes will in fact shut up, when told to.

However it is not obvious to me that HTTP/2.0 is even remotely
similar to NTP in this (or any other) context.

The reason NTP needs this is that there is no person waiting for
the reply packet, it's just feeding into a invisible system service,
which nobody pays attention to anyway (WTF cares if the clock on
a $50 access-point is correct in the first place ?)

With HTTP/2.0 on the other hand, there is a very strong assumption
that somebody will notice if replies does not arrive intact.

So while GOAWAY(AND_DONT_COME_BACK) may (or may not) have its uses,
I suspect that it would catch only a small fraction of protocol
incompatibilties.

The main case we should worry about, is the user looking a the
browser window and thinking "this looks screwy" and by reflex
pressing "reload", repeatedly.

At what point does the user-agent start to suspect HTTP/2.0 and
falls back to HTTP/1.1, how do we get the incident reported on the
server side with sufficient details to be reproduced, and when will
the user-agent try HTTP/2.0 again ?

---

From: James M Snell <[email-masked]>
Date: Wed, 19 Jun 2013 10:51:40 -0700

My objection to this is far stronger as this kind of error code would
likely be complete unenforceable for non-browser implementations. For
instance, if I create a client library stack that is used by multiple
applications, and one application uses the stack in an appropriate way
against example.com, but another abuses the protocol triggering a
"don't come back", how does that affect the first applications ability
to use my library to communicate with example.com? Whose
responsibility is it to persist it and remember? What are the bounds
of that persistence? Is the "don't come back" only a point in time
statement? If so, how long should the client wait? What are the
conditions that would allow the client to come back? What if the
network path changes? As it stands now, the utility of a "don't come
back" is only marginally theoretically useful, let alone something
that ought to be actively implemented. The proposal is on the table, I
am fine with leaving it there for now, but let's leave it on the table
and go focus on the more concrete problems :-)