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

Re: HEADERS and flow control

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 9 May 2014 13:47:24 -0700
Message-ID: <CABkgnnVsFM5oPax+Af1gmg4YO_KHidKA80=OdGfdgZcOh-4jjQ@mail.gmail.com>
To: Hasan Khalil <mian.hasan.khalil@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
/me still needs more information.

This is a change.  The change needs greater justification than "it
might be nice".  So far, that's all I've heard.

I actually think that this is nice.  But nice doesn't cut it for me.

Given the likelihood that header blocks after the first will be used,
this is just another corner case.  If we use HTTP/1.1 as a guide, the
best analogy there is to chunk extensions and trailers, i.e.,
basically zero use.

Is the intent to flow control PUSH_PROMISE too?

(In case you haven't have noticed, I want to finish up here.)

On 9 May 2014 13:21, Hasan Khalil <mian.hasan.khalil@gmail.com> wrote:
> +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.
>> >
>> >
>>
>
Received on Friday, 9 May 2014 20:47:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC