W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Encouraging a healthy HTTP/2 ecosystem

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Tue, 1 Jul 2014 14:29:25 -0700
Message-ID: <CAA4WUYgJunXNe4BbZd9ZVJ8QqXZibJ2J9QyCf493ZtU+Ay4hxA@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Jason Greene <jason.greene@redhat.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 1, 2014 at 2:23 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>

> In message <CAA4WUYhOu0tW_9vSJ4wcLh+V=
> y9h-FfdZjw8Y2kqLp3Bhkcugg@mail.gmail.com>, =?UTF-8?B?V2lsbGlhbSBDaGF
> uICjpmYjmmbrmmIwp?= writes:
> >The impetus is because I've received word of MITM
> >proxies that plan to do deep inspection of HTTP/2.
> > [...]
> >Therefore, I think it's in our
> >interest to make sure that whatever part of the protocol we think is
> >important to preserve for use should be actively exercised.
> And what if the MITM proxies disagree with you about which parts of
> the standard deserve to work and block some of them ?

> What will you do ?

Hard fail. User visible error. End users blame the last mover, therefore we
should move first *if we believe that the functionality is important to
preserve*. In my example about extensions, assuming we think extensibility
should be preserved (I've not heard recent disagreement here, but if I'm
wrong that there's not consensus here, please raise), then we should hard
fail when the extension negotiation fails. Hence attempting to negotiate
dummy extensions and use dummy extension frames to see if they make it

> Pop-up: "EXAMPLE.COM don't agree with Jason Greene about HTTP/2 scope" ?
> Penalize them by deliberately slowing down their traffic ?
> It's a much better idea to make the core protocol so simple that all
> bits of it are naturally exercised.
> --
> 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 Tuesday, 1 July 2014 21:29:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC