[Libwebsockets] Possible bugs - minimal-http-client-multi example
andy at warmcat.com
Thu Sep 17 12:19:53 CEST 2020
On 9/17/20 10:51 AM, Dorit Mari wrote:
> Andy, thank you for your quick response. Please see my answers inline (for first and third issues).
Outlook really wrecks up threads... snipping everything so we can make
out what is what
>>> Dorit: I tried the same input as you "--no-tls --h1 --port 80 --path /status/401 --server httpbin.org -c" - and there was no crash.
>>> When it crashes when accessing my server, it is due to "SIGSEV" signal. "wsi->a.vhost->protocols" has value 0xfeeefeee (the wsi and wsi->a look OK, but wsi->a.vhost doesn't look like it was initialized; it has other members also with values like 0xfeeefeee or -17891602), so we crash when trying to access "wsi->a.vhost->protocols.callback".
>>> I notices the 401 response from httpbin.org is different than the 401 from my server (which can be found below). Notably, there is "Content-Length: 0" in the 401 from httpbin.org, while the >> 401 from my server doesn't contain Content-Length header. Maybe this is relevant?
0xfeeefeee us what debug mode ms C library does to free()d regions, it's
a sign the problem is a kind of use-after-free, in this case the wsi has
been freed but still try to touch it.
But I run my tests all the time under valgrind so I can see this kind of
problem even if it's symptomless, there's no problem like that on the
linux test I described before. So I would guess this is not related to
-multi so much as needs what headers your server sends to provoke it...
if so, you can run the client under valgrind on linux against your local
server, and maybe also see it fail. The first backtrace from that is
usually a big clue about the problem.
>>> Dorit: Please help me make sure I understand correctly the behavior when pipelining (LCCSCF_PIPELINE) is enabled for HTTP 1.1 client - If we have an established, idle connection to some destination, and then we send multiple requests (e.g. HTTP Get) to that destination - will they always be sent serially, each request only sent after the previous request received a response, and all of them on the same TCP/TLS connection? Does the pipelining option (LCCSCF_PIPELINE) only mean reuse of the TCP/TLS connection?
Yes. And Yes, without pipeline, they will go out on individual sockets
/ tls tunnels, without queueing.
>>> I changed the stagger_cb() function, so after the first request we wait 5 seconds. The first request succeeds, and leaves an established, idle TCP connection to the destination. After that, there is 5 milliseconds interval between requests (between calls to lws_try_client_connection()). All the requests are sent on the same TCP connection, serially (only after a request receives a response, we send the next request). Is this the expected behavior?
If it's h1, with pipeline flag, yes. You are making a choice about
trading off serializing accesses for 1 x server connection and 1 x tls
tunnel, for n client transactions.
With h2, the same setup will open all the 5ms interval streams on the
single tcp connection / tls tunnel concurrently, and multiplex the
returned data so they all get serviced round-robin, ie, another (usually
better...) kind of tradeoff.
More information about the Libwebsockets