lws fails to queue connection when mixing IP and Hostname
LWS fails to queue connection when mixing IP and Hostname, the issue occurs due to how lws_client_connect_info fields (address, origin, and host) are configured. Specifically, when the fields are set as follows:
address = IP
origin = hostname
host = hostname
Example:
address = 81.71.211.11
origin = ybt.test.com
host = ybt.test.com
Using an IP address instead of a hostname prevents LWS from performing DNS resolution, as the resolution is handled externally. However, with this configuration, LWS incorrectly compares 81.71.211.11 with ybt.test.com for the second session, treating it as a new session instead of an existing one.
Fix: Ensure consistent comparison by matching IP to IP or host to host. This fix updates the logic to compare IP addresses directly, preventing LWS from incorrectly creating a new session instead of properly queuing it.
Thanks... I don't really want to change the behaviour for the normal case that the address is a DNS name, as this patch seems to do.
For the vast majority of people, they are using TLS and it is based on confirming that the cert that is served and signed by the CA, matches the DNS name.
I understand the behaviour at the moment when using pipelining with an IP address is wrong, but it sounds like the patch should work around that for the explicit IP case only, and leave the normal case as it is.
Thank you, Sir, for the library and your support.
I might be mistaken or perhaps I misunderstood your comment—please bear with me if I’m lacking knowledge here—but I don’t quite see how it changes the behavior. I’d be interested to know if this patch could have any impact.
The patch's goal is simply to compare two elements of the same type. When I mixed IP and hostname in my application, I noticed that a new session was triggered each time I attempted to connect. This was because !strcmp(adsin, w->cli_hostname_copy) compares an IP (adsin) with a hostname (w->cli_hostname_copy).
I combined IP and hostname for the following reasons:
- To leverage the TLS verification on the hostname implemented in the library.
- To prevent LWS from performing DNS resolution, as my application handles DNS resolution and includes an IP affinity mechanism that controls when to stick to an IP and when to switch to another.