Re: Encouraging a healthy HTTP/2 ecosystem

Let's be clear here - we don't want to have a spec that doesn't mirror
reality. If the spec says that something is a core feature, then it's
terrible for it to fail to interop depending on which implementation you
are speaking to.

I think it's a completely fair argument to discuss whether or not
CONTINUATION frames should be a core feature in the spec, or punted off to
be negotiated instead or something. But *if* we keep it as a core part of
the spec, it really must work, and I think it'd be healthy for the
ecosystem if major implementations moved first to exercise as much of the
spec as possible in order to prevent these kinds of interop issues from
appearing.

Please don't hijack this thread to make your debates about CONTINUATION
frames. There are plenty of other threads for that already.


On Tue, Jul 1, 2014 at 8:09 AM, Jason Greene <jason.greene@redhat.com>
wrote:

>
> On Jun 30, 2014, at 10:37 PM, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
>
> >  - 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.
>
> If you are really going to mandate that implementations fully support
> CONTINUATIONS then they need to *at least* be limited by default, and
> negotiated from there.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>