Re: GOAWAY(AND_DONT_COME_BACK)

[James M Snell <[e-mail]>]

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

On Wed, Jun 19, 2013 at 10:38 AM, Poul-Henning Kamp <[e-mail]> wrote:
> In message <CAP+FsNe6Wgso8V-L2xmaptXC01P8OftsH7O3oRjSap=[e-mail]>
> , Roberto Peon writes:
>
>>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.
>
> 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 ?
>
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> [e-mail]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>