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: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 18 Jun 2013 21:52:47 -0700
Message-ID: <CABkgnnWCSw_ZUPwX9abrKP8o4bvRk0GLCUuZETar6oJ_P70r9Q@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: James M Snell <jasnell@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
And merged.

On 18 June 2013 18:02, Jeff Pinner <jpinner@twitter.com> wrote:
> reserved: https://github.com/http2/http2-spec/pull/137
>
>
> On Tue, Jun 18, 2013 at 4:49 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>> +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 Wednesday, 19 June 2013 04:53:15 UTC

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