Re: HEADERS and flow control

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