Re: GOAWAY(AND_DONT_COME_BACK)

In message <CAP+FsNe6Wgso8V-L2xmaptXC01P8OftsH7O3oRjSap=QE7KuxQ@mail.gmail.com>
, 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
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 19 June 2013 17:39:07 UTC