Re: HEADERS and flow control

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.
>
>

Received on Friday, 9 May 2014 20:07:19 UTC