Re: HEADERS and flow control

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