Re: HEADERS and flow control

+1. This sounds like yet another reason that we want a separate opcode for
HEADERS that begin a new stream and those that do not.

Nowhere in this message was SYN_STREAM mentioned. Wait...

On Fri May 09 2014 at 4:09:37 PM, James M Snell <jasnell@gmail.com> wrote:

> This is really the same issue that I had brought up quite a while
> ago... in the context of hop-by-hop or end-to-end frame types, where
> end-to-end frames were always considered to be subject to flow
> control. While I contend that it still makes far more sense to define
> it as a property of the opcode, having a flow-control headers frame
> variant could work also.
>
> On Fri, May 9, 2014 at 12:37 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > Or you can change the opcode of the other HEADERS...
> >
> > What I'm proposing is effectively a rethink of the merging of HEADERs and
> > SYN_STREAM, because users have brought up usecases which would be
> > troublesome with the way it is done now.
> > -=R
> >
> >
> > On Fri, May 9, 2014 at 12:34 PM, Martin Thomson <
> martin.thomson@gmail.com>
> > wrote:
> >>
> >> On 9 May 2014 12:10, Roberto Peon <grmocg@gmail.com> wrote:
> >> > What creates a surprising corner case?
> >>
> >>
> >> What you are proposing:
> >>
> >> function isFlowControlled(frame) {
> >>   return frame.type === 'DATA';
> >> }
> >>
> >> becomes:
> >>
> >> var firstHeadersDone = false;
> >> function isFlowControlled(frame) {
> >>   if (frame.type === 'DATA') {
> >>     return true;
> >>   }
> >>   if (!firstHeadersDone) {
> >>     if (frame.type === 'HEADERS' || frame.type === 'CONTINUATION') {
> >>       firstHeadersDone = frame.flags.END_HEADERS;
> >>     }
> >>     return false;
> >>   }
> >>   return frame.type === 'HEADERS' || frame.type === 'CONTINUATION';
> >> }
> >>
> >> Or something like that.  That's not particularly straightforward.
> >> Such complexity requires justification.
> >
> >
>
>