[Libwebsockets] Settings Frame size above max / Flow control exceeded max
andy at warmcat.com
Mon Jul 8 17:20:36 CEST 2019
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
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.
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
> 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.
> 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:
>> ./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
> 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?
More information about the Libwebsockets