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

https://github.com/http2/http2-spec/pull/136 to reverse the polarity of
CONTINUES and rename FINAL -> END_STREAM and CONTINUES -> END_HEADERS


On Tue, Jun 18, 2013 at 1:42 PM, Roberto Peon <grmocg@gmail.com> wrote:

> END_HEADERS indicates the end of a header block.
> END_MESSAGE indicates the end of a message, which could be metadata only,
> or it could be metadata+data.
> END_MESSAGE is necessary because END_HEADERS is insufficient to indicate
> the end of a message. It would only be sufficient if we knew that messages
> were only headers.
>
> END_MESSAGE should not be allowed on any headers frame where END_HEADERS
> is not true.
>
> I see Jeff replied before I got this email sent.
> What he said too :)
> -=R
>
>
> 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.
>>
>>
>