W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

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

From: James M Snell <jasnell@gmail.com>
Date: Tue, 18 Jun 2013 16:49:32 -0700
Message-ID: <CABP7Rbf_Xnb0Yfh0XEkhAp2WUsYgL1Kfh-YL7PaNhBfqG7edCg@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
+1 to END_STREAM and END_HEADERS, +1 to reserving 0x2 for END_MESSAGE
later on but -1 to including it in this implementation draft.

On Tue, Jun 18, 2013 at 11:39 AM, 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.
>
> For compression, the text can then read something like "a header block is
> compressed and encoded according to <link header compression spec> and
> serialized in a sequence of HEADERS frames... frames that comprise an
> encoded header block must be written sequentially and cannot be interleaved
> with other frames... the final frame in the sequence must be identified by
> setting the END_HEADERS flag" (re-written by our editors to make it easier
> to understand)
>
>
>
> On Sat, Jun 15, 2013 at 9:45 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>>
>> From an implementation point of view a default value of 0 for both flags
>> is easiest of all to implement, with polarity of 1 being set for the
>> exceptional cases.
>>
>> The bulk of frames in a stream will *not* be the FINAL frame. Likewise the
>> bulk of headers delivered will likely be small enough to *not* have a
>> CONTINUES necessary.
>>
>> So to me the existing polarity seems to be correct. I propose renaming the
>> CONTINUES flag to "EXTEND" (extended headers present) or "LARGE" (large
>> header set) or "MULTI" (multiple header blocks) or something else  avoiding
>> the unfortunate wording overlap with the FINAL semantics description.
>>
>> Amos
>>
>>
>> On 16/06/2013 12:49 p.m., Roberto Peon wrote:
>>>
>>> no objections here with the proposal.
>>>
>>>
>>> On Sat, Jun 15, 2013 at 5:15 PM, James M Snell <jasnell@gmail.com
>>> <mailto:jasnell@gmail.com>> wrote:
>>>
>>>     And fwiw, I already had a note for this in my list of todos
>>>     following the interim.
>>>
>>>     On Jun 15, 2013 5:13 PM, "James M Snell" <jasnell@gmail.com
>>>     <mailto:jasnell@gmail.com>> wrote:
>>>
>>>         +1... consistency makes the most sense.
>>>
>>>         On Jun 15, 2013 5:06 PM, "William Chan (ι™ˆζ™Ίζ˜Œ)"
>>>         <willchan@chromium.org <mailto:willchan@chromium.org>> wrote:
>>>
>>>             I don't particularly care. I just want to point out that
>>>             the reason it "natural" to do it the way it's already
>>>             done, is FINAL and CONTINUES are the exceptional cases. So
>>>             to the degree that it's nicer to by default have no flags
>>>             set, the current approach is better. I don't have any
>>>             paint to waste on this bike shed though.
>>>
>>>             On Sat, Jun 15, 2013 at 4:57 PM, Mike Belshe
>>>             <mike@belshe.com <mailto:mike@belshe.com>> wrote:
>>>
>>>                 I agree on the consistency issue Dave presents.  I
>>>                 also like Dave's suggestion to use 1 to mean final
>>>                 everywhere.
>>>
>>>                 Mike
>>>
>>>                 process question:  is it valuable to reply in github?
>>>                  or is the list preferred?
>>>
>>>
>>>             Always the list. If you see much discussion on github,
>>>             yell at them to bring it to the list. And any
>>>             commits/issues/updates on github should reference the
>>>             rough consensus from the mailing list.
>>>
>>>
>>>
>>>
>>>                 On Sat, Jun 15, 2013 at 4:14 PM, David Morris
>>>                 <dwm@xpasc.com <mailto:dwm@xpasc.com>> wrote:
>>>
>>>
>>>
>>>                     This issue:
>>>
>>>                     https://github.com/http2/http2-spec/issues/129
>>>
>>>                     describes my concern that the polarity is reversed
>>>                     between STREAM FINAL
>>>                     and HEADER CONTINUES which are both flag bits used
>>>                     to manage continuation.
>>>
>>>                     I think this will introduce confusion to folks
>>>                     analyzing wire level bits
>>>                     as well as reading code.
>>>
>>>                     I do acknowledge the the current flag names match
>>>                     the sense of the
>>>                     polarity so the names probably should change.
>>>
>>>                     Dave Morris
>>>
>>>
>>>
>>>
>>
>>
>
Received on Tuesday, 18 June 2013 23:50:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC