[Libwebsockets] Settings Frame size above max / Flow control exceeded max

Andy Green andy at warmcat.com
Sun Jul 7 13:42:06 CEST 2019



On 7/7/19 11:42 AM, Andreas Lobbes wrote:
> Hi,
> 
> I try to make a https-request. In contrast to other sites, for this 
> specific site the request does not succeed.
> The only hint I found in the log (see below) is "INF lws_h2_goaway: 
> 0x55ebbce7ca20: ERR 0x1, 'Settings Frame size above max'". I suppose 
> this is the root cause. Any I idea what that does mean?

Well, props for sending usable logs from the get-go.

> 2019-07-07 11:34:56 INF http2 settings 3 <- 0x80
> 2019-07-07 11:34:56 INF http2 settings 4 <- 0x10000
> 2019-07-07 11:34:56 DBG _realloc: size 56: pps
> 2019-07-07 11:34:56 INF lws_h2_goaway: 0x55ebbce7ca20: ERR 0x1, 
> 'Settings Frame size above max'

The peer is sending a huge max frame size... above 16M-1 we're supposed 
to reject it with PROTOCOL_ERROR like this.  But actually, we reject it 
at 8M-1 as it is... it's a bug... I pushed a patch on v3.1-stable and 
master that fixes it.

Although it's a bug to reject it... actually huge frame sizes 16M or 8M 
generally don't make any sense... not just for latency (they would block 
muxing until all 8M or 16M was sent) but for scalability, 1000 peers 
taking it up on these monster frames and sending the on different 
connections could allocate up to 16GB heap then.  So the peer should not 
really be advertising this even though it's legal.

> 2019-07-07 11:34:56 INF LWS_H2_FRAME_TYPE_WINDOW_UPDATE
> 2019-07-07 11:34:56 INF WINDOW_UPDATE: sid 0 2147418112 (0x7fff0000)
> 2019-07-07 11:34:56 DBG _realloc: size 56: pps
> 2019-07-07 11:34:56 INF lws_h2_goaway: 0x55ebbce7ca20: ERR 0x3, 'Flow 
> control exceeded max'

The tx credit window is not allowed to exceed 0x7fffffff.  The peer also 
took a maximalist approach and told us we should bump our tx credit by 
0x7fff0000.  Unfortunately it told us its tx credit was 0x10000 and we 
adjusted our side to that already, so it comes to 0x80000000 IIUI.

Again tx credit window is a scheme to dynamically stop streams 
monopolizing the multiplexed wire protocol... the combination of huge 
frames and a license for any stream to spam 128 of those in succession 
won't give good results for other streams or latency if the peer takes 
them up on it.

-Andy


More information about the Libwebsockets mailing list