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

Andy Green andy at warmcat.com
Tue Jul 9 18:41:42 CEST 2019



On 7/9/19 4:53 PM, Andreas Lobbes wrote:

> 2019-07-09 17:20:15 DBG __lws_set_timeout: 0x557ddd120a20: 31 secs (reason 15)
> 2019-07-09 17:20:15 DBG 0x557ddd120a20 (0x557ddd1395e0): fr hdr: typ 0x3, fla 0x0, sid 0x3, len 0x4
> 2019-07-09 17:20:15 INF lws_h2_parse_frame_header: wsi 0x557ddd1395e0, State: LWS_H2S_HALF_CLOSED_LOCAL, received cmd 3
> 2019-07-09 17:20:15 INF lws_h2_state: wsi 0x557ddd1395e0: state LWS_H2S_HALF_CLOSED_LOCAL -> LWS_H2S_CLOSED
> 2019-07-09 17:20:15 INF LWS_H2_FRAME_TYPE_RST_STREAM: sid 3: reason 0x1
> 2019-07-09 17:20:15 DBG __lws_set_timeout: 0x557ddd120a20: 31 secs (reason 15)
> 2019-07-09 17:20:15 DBG 0x557ddd120a20 (0x557ddd120a20): fr hdr: typ 0x7, fla 0x0, sid 0x0, len 0x8
> 2019-07-09 17:20:15 INF lws_h2_parse_frame_header: wsi 0x557ddd120a20, State: LWS_H2S_IDLE, received cmd 7
> 2019-07-09 17:20:15 DBG LWS_H2_FRAME_TYPE_GOAWAY received
> 2019-07-09 17:20:15 INF GOAWAY: last sid 3, error 0x00000006, string ''
> 
> I re-enabled hexdump in lws_ssl_capable_read().

You probably want to do the same on the write...  -->

> The error code 6 in last line of log does mean "Frame size incorrect"
> according to: https://www.iana.org/assignments/http2-parameters/http2-parameters.xhtml#error-code
> I'm also on it..

If it's complaining about frame size, presumably it thinks something 
wrong with what we sent it.

-Andy

> State of the library source is: HEAD of branch 3.1 (73a4f86b) + cherry pick 3b44a745 of master
> 
> Regards,
> Andreas
> 
> ________________________________________
> From: Andy Green [andy at warmcat.com]
> Sent: Monday, July 08, 2019 5:20 PM
> To: Andreas Lobbes; libwebsockets at ml.libwebsockets.org
> Subject: Re: [Libwebsockets] Settings Frame size above max / Flow control exceeded max
> 
> On 7/8/19 3:58 PM, Andreas Lobbes wrote:
>> Hello Andy,
>>
>> success, I get the same response (400).
>> OAuth is just a small subtask, to secure access to a WSS-Server (via bearer access token).
> 
> OAUTH2 isn't that small a task... I wanted to point out lws has JOSE
> pieces, and there is a new tool on master, 'lws_sequencer_t' that should
> help sequence and coordinate the various connections and states needed,
> while still operating on the event loop, with its own timeout.
> 
> This may not seem particularly relevant at first, but consider OAUTH
> sequencing wants three separate http conversations that have to happen
> sequentially and each using information from the previous step.  Since
> there's no single wsi involved, without lws_sequencer_t it is actually
> difficult to coordinate this, and not really possible to do it in the
> same event loop context.  Which means the alternative solutions are not
> really reusable.
> 
> lws_sequencer_t is designed to sit above wsi lifetimes and receive
> messages from the wsi protocols (or other threads) which are queued
> until the sequencer receives them in the event loop.  From there it can
> track state for a task (eg, OAUTH) that is longer-lived than any one wsi
> it's using, manage retry / reconnect etc.
> 
> https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.lws_sequencer.md
> https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-sequencer.h
> 
> API unit test fetching 5 x URLs in sequence, one of which is expected to
> time out and another which is expected to fail to connect
> 
> https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/api-tests/api-test-lws_sequencer/main.c
> 
>> Main part is to bridge traffic from pipe/socket to WSS.
> 
> Not sure what that means to you, but eg lws supports RAW unix domain
> sockets... that can put stuff in a ringbuffer (lws_ring) that's taken
> out by a wss protocol wsi... or vice versa... this is the easier part
> compared to OAUTH2 I think.
> 
> -Andy
> 
>> Andreas
>>
>>
>> ________________________________________
>> From: Andy Green [andy at warmcat.com]
>> Sent: Monday, July 08, 2019 12:43 PM
>> To: Andreas Lobbes; libwebsockets at ml.libwebsockets.org
>> Subject: Re: [Libwebsockets] Settings Frame size above max / Flow control exceeded max
>>
>> On 7/8/19 10:56 AM, Andreas Lobbes wrote:
>>
>> Thanks.
>>
>>> ./libwebsockets-test-client -ohttps://account.dev.azdev.ezeep.com/oauth/access_token
>>
>> I can reproduce it... it's setting the HPACK dynamic size to 0
>>
>> [2019/07/08 11:16:10:4279] INFO: lws_hpack_dynamic_size: from 8192 to 0,
>> lim 65536
>>
>> https://tools.ietf.org/html/rfc7541#section-6.3
>>
>> doesn't seem to say that has any special meaning other than the dynamic
>> table should be emptied out and get a size of 0.  Then it sends a new
>> entry for the now zero-sized dynamic table
>>
>> [2019/07/08 11:16:10:4281] HEADER:  HPKT_INDEXED_HDR_6_VALUE_INCR (hdr 54)
>>
>> ... I assume it's a convention that 0 means it should empty the dynamic
>> HPACK table while keeping the allocation the same.
>>
>> I pushed on master a patch to implement that and another to add a vhost
>> option flag to fix up overflowed WINDOW_UPDATE (and added the flag to
>> the test client).
>>
>> With that I can get a 400 cleanly.
>>
>> Are you interested in implementing OAUTH client?
>>
>> -Andy
>>


More information about the Libwebsockets mailing list