[Libwebsockets] Possible bugs - minimal-http-client-multi example

[Andy Green]

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).
s/401)

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[0].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.

-Andy