Re: HEADERS and flow control

How would the interaction of stream flow control and continuations be
managed? A stalled stream may also stall the connection, including control
frames. Could that also lead to deadlock?


On Fri, May 9, 2014 at 6:18 PM, Roberto Peon <grmocg@gmail.com> wrote:

>
>
>
> On Fri, May 9, 2014 at 1:47 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> /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 have non-browser customers who are looking at HTTP2 as it stands right
> now and are pointing out that this will become problematic if HEADERS is
> actually used as metadata (as it was intended to be) as opposed to simply
> to create streams. There is no guarantee that the metadata is going to be
> small. They're mostly willing to swallow the idea that a large block of
> metadata would (effectively) pause multiplexing for a short time, but
> worried about the fact that this large metadata actually could account for
> a fair bit of buffer, and that the product that HTTP2 (etc) would replace
> did have an operational problem with the lack of this in the past.
>
>
> Hmm.. in scanning the document I think we don't have the requirement in
> there that HEADERS and DATA have a sequence relationship that must be
> maintained. We've spoken about it numberous times, but I think we
> overlooked getting that in there.
>
>
>> 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?
>>
>
> No-- PUSH_PROMISE is necessary for stream creation. Flow controlling it
> might engender protocol-induced deadlock.
>
>
>>
>> (In case you haven't have noticed, I want to finish up here.)
>>
>
> I know. I'll point out I haven't been making trouble unless I have people
> actually wanting to use the HTTP2 for stuff!
> Better, the folks who are complaining about this to me are creating
> implementations now, and as far as I can tell, no-one else out there is.
> That implies that this change will not slow down interop.
> -=R
>
>