[Libwebsockets] a question about log info for 302 redirection

[Andy Green]

On 11/2/20 2:14 PM, huangkaicheng wrote:
> Thanks. I get relocated info successfully from “_WSI_TOKEN_CLIENT_URI”as 
> you said .
> 
> Then, at the situation of relocating, I found that libwebsockets print 
> quite a lot about" SSL Capable more service" logs after wss client 
> establish success.

This isn't anything to do with the relocation, it's openssl telling us 
that he cannot proceed, probably not without either a POLLOUT or POLLIN 
/ rx data.

> I want to know whether it is normal about " SSL Capable more service ".

Short story is getting them is normal, and they are handled "correctly", 
in the sense it's for the right result.  But it's not optimal as it is.

Long story is openssl itself, over its own versions and the platform / 
SYSCALL api, is a bit of a mess about this, its related return codes 
have changes meanings more than once between versions.  Both mbedtls and 
openssl have the idea that apis can return WANT_READ or WANT_WRITE type 
results, but with SYSCALL and possibly random drying up, at least 
openssl can return a generic "there's no error but you'll have to retry 
this", eg, EAGAIN type semantics.

Lws converts the completely different api result codes for openssl and 
for mbedtls into a common set, in order that we don't get bugs coming 
depending on mbedtls or openssl.

	LWS_SSL_CAPABLE_ERROR			= -1, /* it failed */
	LWS_SSL_CAPABLE_DONE			= 0,  /* it succeeded */
	LWS_SSL_CAPABLE_MORE_SERVICE_READ	= -2, /* retry WANT_READ */
	LWS_SSL_CAPABLE_MORE_SERVICE_WRITE	= -3, /* retry WANT_WRITE */
	LWS_SSL_CAPABLE_MORE_SERVICE		= -4, /* general retry */

If there is network traffic or POLLOUT that it is waiting on, we will 
get an event on the event loop and wake up and deal with it.  But if it 
doesn't have any specific reason we can observe, eg, /dev/random is dry, 
we will not get a wake event, yet it may become ready.

So under some conditions atm we return the generic MORE_SERVICE and go 
around the event loop with the poll() or select() wait defeated, or the 
tls connect times out, since we neither know what we're waiting for nor 
what will trigger it.

This code evolved and improved over the years and for a while the 
underlying code checks SSL_want_read() and _write() explicitly to try to 
shed some light on what we might be waiting on.  But still at the moment 
paths return MORE_SERVICE and end up in the generic event loop handler, 
basically we are trading some more times around the event loop for 
correct operation on all tls libs and platforms.

Some happy day it will get refactored into the explicit WANT_READ/_WRITE 
propagated up to the top and handled differently, and the extra event 
loop trips optimized out.  But unless you get a big urge to send me 
patches, since it works well already it will have to wait its turn.

-Andy