Re: HEADERS and flow control

I think the simplest solution is to just include all headers in the flow
control calculations.

I believe that the argument against this (ie dead locks) is erroneous
because server may still reject important requests if they are resource
constrained, so dead lock is not avoided it is just moved to the
unknown.    With headers included in flow control, clients would have a
solid contract with the server and would know ahead of time if a request
can be sent or not.

Senders should not commence sending a headers unless there is sufficient
window available to send all the frames.     I know this effectively
prohibits streaming headers, but then streaming headers is beyond the scope
of http2 as it is not something that http/1.1 commonly supports anyway.

If we really need to support headers larger that can fit in a single frame,
then we could add a flag that set subsequent header sets sent should be
aggregated.  ie a hpack header set would have to be sent in a single frame
(making the ordering of decoding easy), but that subsequent sets could be
aggregated to make larger headers sets.  This allows other streams to
interleave frames between the aggregated header frames.

cheers






On 28 May 2014 23:31, Johnny Graettinger <jgraettinger@chromium.org> wrote:

> Looping back to the OP:
>
> Under the current draft, one way in which peers could effectively
> negotiate flow-control for HEADERS is first send empty DATA frame(s) padded
> to the HEADERS size. This could be made efficient if DATA frames were able
> to express flow-control commitment beyond the wire size of the frame. Is
> there interest in this?
>
> There are lots of ways this could be conveyed, but the least disruptive
> may be as a DATA frame with padding larger than the frame size.
>
>
> On Wed, May 28, 2014 at 10:08 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>
>> On 28 May 2014 09:35, Greg Wilkins <gregw@intalio.com> wrote:
>> > If the resource constrained server does not have the resources to
>> accept the
>> > 250B extra header, it can RST_STREAM, but it still has to process the
>> > headers, because of the shared state table.   So if the server really is
>> > resource constrained, and wants to limit the resources of each
>> connection,
>> > then it wont just RST_STREAM, it will GO_AWAY the whole connection -
>> and all
>> > the work in progress on all the other streams will be lost!
>>
>> Yes, if you can't tolerate the work that updating the header table
>> requires, then I suspect that you might find you are best dropping
>> connections.
>>
>> I don't see any intrinsic problem with this.  We've delegated the
>> state commitment management to the HTTP layer: the 431 status code,
>> specifically.  That makes more sense to me, since header processing is
>> a function of that layer.  RST_STREAM remains as a secondary option.
>> GOAWAY as a measure of last resort.
>>
>>
>


-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.