Re: H2 HEADERS and flow control

David,

I think we are talking at cross purposes!

I'm not talking about situations that do not happen under normal
conditions.   For better or for worse, large cookies and big kerberos
tickets are normal.

Just sending a 32KB header is not sufficient reason to be flow controlled
nor be rejected with a 420 EYC style response.   If the server supports
large headers, then this is perfectly allowable. I'm  just saying that it
should move you 32KB closer to being flow controlled (at least for frames
that can be flow controlled).


cheers










On 4 July 2014 17:18, David Krauss <potswa@gmail.com> wrote:

>
> On 2014–07–04, at 1:54 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
> > Whilst what I'm advocating could be somewhat implemented by self
> control/priorty I don't think it can entirely be done so, and certainly not
> just by the server.
> >
> > Currently a browser that has just sent a 64KB header is free to
> immediately send another 64KB of data without any say so from the server.
>  This will effectively give that client twice the share of any shared
> connections from load balancer to app server vs a browser that sends small
> headers.
>
> Too many requests is exactly what ENHANCE_YOUR_CALM is for. It’s not
> supposed to happen under normal conditions, i.e. it’s an indication of
> trouble.
>
> > If the header size was included in the flow control calculations, then
> the browser would have to wait for a WINDOW_UPDATE after sending a 64KB
> header before it could send any data.   It would thus be only able to take
> the same share of any amalgamated connection as a small header sender.
>
> TCP window updates do the job you’re asking for. The load balancer should
> simply delay reading the delinquent socket at the time it sends or forwards
> ENHANCE_YOUR_CALM.
>
> To be sure, this sucks for other users sharing the same client-side proxy
> (assuming it aggregates connections). But that raises doubt of whether
> equal sharing of server resources is a useful goal in the first place.
>
>


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