[Libwebsockets] Trying to get protocol callback mount to work
andy at warmcat.com
Wed Oct 10 20:20:26 CEST 2018
On October 11, 2018 12:01:53 AM GMT+08:00, Alex Stagg <alex at bitrouter.com> wrote:
>I have client and server test programs using libwebsockets to simulate
>client-initiated websockets connection without a (websockets
>name, and get the server to assign it to one of several protocol
>based on the URL.
I guess it's already obvious, but having the client just specify the ws subprotocol is what ws and lws expect you to do, and it will just work for identifying which lws_protocols to bind to.
>When I specify a protocol string in the client connection info that
>the name of protocol 1 on both sides, the connection is assigned to
>1 on both sides, as I would expect. If I specify NULL as the protocol
>pointer in the client connection info, then I get the connection
>protocol 0 on both sides as normally expected without using URL mounts.
Okay, but mounts are an http thing. At the time you try to upgrade the http connection to ws, not GET or PUSH, they are not consulted.
>Am I incorrect in understanding that properly configuring URL mounts
>the connection with no protocol from the client side assigned to
>(at least on the server side)? If so, I have not been able to get this
Nothing claims that would work on lws side for ws... the mount support for CALLBACK mounts is only for http, as used in the POST example plugin to bind a chunk of URL space to be handled by that plugin.
Not having a subprotocol means there's a 'default' protocol per-vhost that gets mapped at upgrade time (itself defaulting to protocol 0). If the upgrade has the subprotocol header, then that alone selects the protocol it binds to, by name matching.
>work regardless of how I try to match values in the server's struct
>lws_http_mount with the client's connection info, and the protocol
>What info would someone need to help me debug this?
The only bug in this is your client thinks not sending the ws subprotocol name was a good idea and the limitations caused by it being a bad idea should be hacked around in lws.
If you're stuck with that, notice that the parsed http headers are still available at ESTABLISHED. You can fish out the URL part there and set your own function pointer held in the pss to the correct handler. Then in your single lws protocol, call through to the sub-handler you selected at ESTABLISHED time. Or some variation of that.
>* Alex Stagg
More information about the Libwebsockets