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

Re: #549: END_STREAM flag on CONTINUATION

From: Jeff Pinner <jpinner@twitter.com>
Date: Sun, 20 Jul 2014 16:59:56 -0700
Message-ID: <CA+pLO_iLa7ZUq0qwCwA57siYLY1xzqw_=+LOTRcemkzKUS7FFg@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Jul 20, 2014 at 3:00 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <A8DFE59E-E342-4833-BA40-AD81B2A646D9@mnot.net>, Mark Nottingham wri
> tes:
>><https://github.com/http2/http2-spec/issues/549>
>
>>>      * CONTINUATIONS are in most respects a way to create a single
>>>        frame from many. Logically, they are part of the preceding
>>>        HEADERS/PUSH_PROMISE. Adding some flags from the preceding
>>>        frame but not others is conceptually muddy.
>
> The fundamental problem is that CONTINUATIONS started for
> one reason (superframes) and got hi-jacked for something
> else (pipelining) which gives them the horrid exceptional
> behaviour in the current draft.


> At the very least that means that the END_STREAM bit goes on the
> last frame on the stream, be it a HEADERS, PUSH_PROMISE or a
> pipelining CONTINUATION frame.

Moving all of the flags to the last CONTINUATION frame requires even
more error handling.

Moving just one of the flags is yet another exceptional case that
requires more logic.

The flags used to be on the last frame and were moved to simplify
implementations. Moving them back is just adding implementation
complexity for no good reason.
Received on Monday, 21 July 2014 00:00:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:20 UTC