[Libwebsockets] lws_client_connect_via_info() - protocol 0 handler
denis.osvald at sartura.hr
Wed Feb 15 11:55:15 CET 2017
On 2017-02-15 10:46, Andy Green wrote:
> On 02/15/2017 05:31 PM, Denis Osvald wrote:
>> On 2017-02-15 02:18, Andy Green wrote:
>>> On 02/15/2017 01:50 AM, Joel Winarske wrote:
>>> That doesn't mean much though since it knows it will generate callbacks
>>> in the process of connecting, and when no better protocol is capable of
>>> being selected (because for ws it must be negotiated with the server),
>>> lws uses protocols for want of anything better in many places.
>>> Client connections were until recently all ws/wss, for that this will
>>> work fine since the protocol is negotiated and selected later.
>>> For HTTP[S] client until now no code to allow forcing the protocol
>>> selection... that works fine with all on protocols in "by hand" code
>>> like the original test server. But being able to target a specific
>>> plugin / protocol handler by name makes a lot more sense inside lwsws.
>>> Please try this
>>> pushed on master just now.
>>> Set the info .vhost, the protocol name you want on that vhost in the
>>> info .protocol and there should be an info.method set already indicating
>>> http GET or whatever. Then it will attempt to select the protocol from
>>> the vhost early in the connection action.
>> Hmm, I don't seem to get what this change does exactly. Would
>> protocols still be called for things like:
>> - FD / extpoll stuff
>> - extra SSL info callbacks
>> - client connection error (CCE)
>> - callbacks before we know we'll upgrade to ws(s)
>> - callbacks after we've upgraded to ws(s)
>> - callbacks after we know no upgrade to ws(s) will happen
>> (Does the last type of client callback even exist?)
>> In other words, what callback reasons are moved from protocols to the
>> selected-by-name protocol callback?
> Absolutely none, unless in the client connect info:
> - you gave a method, like "GET"
> - you gave a vhost
> - you gave a protocol name
> Normally, giving a protocol name along with a method has no meaning,
> since until now the protocol name was only used by ws[s] processing and
> giving the method means you are doing HTTP[S] processing. So *no
> existing code meets these criteria*.
> If you do give those things in the connect info, the callback for most
> http things is the one in the named protocol. But you have had to go
> out of your way to ask for that on your http client connection info.
> And in client-on-lwsws, that is what you want since you have control
> over the plugin and can handle his http client messages there.
> For extpoll, the stuff that calls that explicitly uses protocols, so
> it's unaffected.
> This can't affect anything related to ws[s] client connections, because
> the precondition of the method being set means we are not doing ws[s].
> Make sense?
Yes, that's good to hear.
So just to confirm my understanding, we could have always done:
- method=NULL, vhost=..., protocol="abc"
-> we want websocket protocol "abc" through "abc" protocol cb
- method="GET", vhost=..., protocol=NULL
-> we want plain HTTP GET (no upgrade) through protocols cb
With the new change we can also do:
- method="GET", vhost=..., protocol="abc"
-> we want plain HTTP GET (no upgrade) through "abc" protocol cb
Did I get this right?
A tangentially related question - is it possible somehow to say "I want
to use xyz protocol cb, and upgrade to WS if possible, otherwise stay
with plain HTTP client connection" (i'm almost sure that the answer is
no, and that this should be done in a separate connect attempt when I
know that WS won't work for whatever reason)?
>> Denis Osvald
>>>> Libwebsockets mailing list
>>>> Libwebsockets at ml.libwebsockets.org
>>> Libwebsockets mailing list
>>> Libwebsockets at ml.libwebsockets.org
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets