[Libwebsockets] a question about log info for 302 redirection
andy at warmcat.com
Mon Nov 2 15:57:15 CET 2020
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.
More information about the Libwebsockets