Re: Issue re. HTTP2 STREAM and HEADER block use same end bit polarity

I am going to make a completely contrived example to try to illustrate my
thoughts:

Let's say I have a message based protocol that tries to send the following
messages over stream 1:

Content-Type: text
Message 1

Content-Type: json
{message_id: 2}

This could be done by encoding the following frames on stream 1:

Stream-Id 1 HEADERS(END_HEADERS): Content-Type: text
Stream-Id 1 DATA(END_MESSAGE): Message1
Stream-Id 1 HEADERS(END_HEADERS): Content-Type: json
Stream-Id 1 DATA(END_STREAM,END_MESSAGE): {message_id: 2}

Now for the sake of argument lets say that the frame length was so small
that "Content-Type" couldn't fit completely in the frame. Then the client
would have to send the following:

Stream-Id 1 HEADERS: Content-
Stream-Id 1 HEADERS(END_HEADERS): Type: text
Stream-Id 1 DATA(END_MESSAGE): Message1
Stream-Id 1 HEADERS: Content-
Stream-Id 1 HEADERS(END_HEADERS): Type: json
Stream-Id 1 DATA(END_STREAM,END_MESSAGE): {message_id: 2}

In any case -- the point here is to illustrate that concatenation of header
blocks for decoding is completely orthogonal to the possible existence of
messages and their boundaries.

- Jeff


On Tue, Jun 18, 2013 at 11:53 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 18 June 2013 11:39, Jeff Pinner <jpinner@twitter.com> wrote:
> > A suggestion for the HEADERS frame flags that incorporates "FINAL",
> > "MSG_DONE", and changes the polarity of "CONTINUES:"
> >
> > 0x1: END_STREAM - indicates that this frame is the last the endpoint will
> > send on the identified stream.
> > 0x2: END_MESSAGE - indicates that this frame comprises a message
> boundary.
> > 0x4: END_HEADERS - indicates that this frame marks the end of the encoded
> > header block.
>
> I like this generally, however I'm struggling with the distinction
> between END_MESSAGE and END_HEADERS.
>
> I can appreciate the logical purity of the argument for a distinction,
> but I can't see a practical benefit to it.  END_HEADERS implies
> concatenation, but END_MESSAGE just ...ends?  I'm not sure then what
> you do with a sequence of frames that form a message, if you aren't
> concatenating them. Websockets APIs concatenate.
>
> If this is about the hard lock-out that we have when HEADERS are
> continued, that doesn't need a special signal, just some text.
>