- From: Jeff Pinner <jpinner@twitter.com>
- Date: Tue, 18 Jun 2013 11:39:25 -0700
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CA+pLO_gg_Gu4riWAqSaGS_zfjQZ4tZLVY3C9isybgEy0YoAwmg@mail.gmail.com>
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<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 18:39:55 UTC