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: Mon, 30 Jun 2014 23:30:40 -0700
Message-ID: <CAA4WUYj1Qb_cNWQ1LA=nEug3r8F6G5R8B_W-nkMB4Mqbk3od7A@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Try not to be too combative here :) I specifically caveated CONTINUATION
with an "If we think servers need to at least be able to support reading
continuation frames." In this thread, I'm not trying to debate the
controversial stuff. I'm just trying to get a list of the stuff we have a
relatively strong consensus around and how we keep those usable.


On Mon, Jun 30, 2014 at 11:23 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <CAA4WUYgqE02o9jftm1ERJGsKBqau9CRAJ4=
> JF0r3x-11gh5ZXQ@mail.gmail.com>, =?UTF-8?B?V2lsbGlhbSBDaGF
> uICjpmYjmmbrmmIwp?= writes:
>
> >This has come up in a number of different discussions over time, and I
> >thought it'd be nice to gather a list of things that it'd be useful if
> >major implementations did in order to keep the ecosystem healthy.
>
> The best way to "keep the ecosystem healthy" is to write a good and
> simple standard without bogus misfeatures like CONTINUATION.
>
> >* Make sure to use features that aren't necessarily required, in order to
> >make sure they remain viable. For example:
> >  - If we think servers need to at least be able to support reading
> >continuation frames (if not necessarily use them themselves), then clients
> >should make sure to exercise this code path some part of the time.
>
> You have heard a rather large number of intermediaries say clearly that
> they will not implement CONTINUATION, trying to force them to using this
> sort of "blackmail" ain't gonna make you and your browser any friends.
>
> --
> 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 06:31:07 UTC

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