Re: #549: END_STREAM flag on CONTINUATION

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.

If HTTP/2's framing layer really had superframes, they would work
for all frame-types, and all frames but the last in a superframe
would have the "... continued" bit set and nothing would
get between the frames of a superframe.  The upper layers would not
even see CONTINUATION frames, but just one large HEADERS superframe.

But that wouldn't work for pipelining, so the semantics got tweaked
and twisted to make pipelining possible without (too much) HOL
blocking.

Now that we have support longer frames, we should clean the superframe
aspect out of CONTINUATION, and define them purely in terms of their
pipelining role.

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.

If we further add that no HTTP header can span frames, the question
of HPACK state disappears, and the multiplexing restrictions can
be removed.


-- 
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 Sunday, 20 July 2014 22:00:58 UTC