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


From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 21 Jul 2014 08:04:15 +0000
To: Jeff Pinner <jpinner@twitter.com>
cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <35319.1405929855@critter.freebsd.dk>
In message <CA+pLO_iLa7ZUq0qwCwA57siYLY1xzqw_=+LOTRcemkzKUS7FFg@mail.gmail.com>
, Jeff Pinner writes:
>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:
>>>>      * 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.

Are you suggesting that ?  I havn't seen anybody else do so ?

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

I think it makes everything much easier if END_STREAM always sits
on the packet which closes the stream.

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 Monday, 21 July 2014 08:21:00 UTC

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