[Libwebsockets] protocol plugin

Andy Green andy at warmcat.com
Sun Feb 5 22:14:44 CET 2017



On February 6, 2017 2:56:03 AM GMT+08:00, Joel Winarske <joel.winarske at gmail.com> wrote:
>It seems it only looks at the first defined vhost.  If I move the
>primary
>site vhost to the bottom of the config, it no longer loads the site,
>and I
>see LWS_CALLBACK_HTTP.

Determining which vhost to serve happens one of two ways...

 - if ssl is in use, the SNI feature is used to match what it sends against the vhost name.  This allows use of the correct cert for the vhost before the ssl tunnel is established.

 - if no ssl, the Host: header contents are matched against the vhost names.

So turn up the logging and see what you're sending from your client for Host:.

For backwards compatibility if lws only has one default vhost all protocols are enabled on it.  With multiple vhosts they must be enabled individually on the vhost you want to have access to them.

-Andy

>On Sun, Feb 5, 2017 at 9:50 AM, Joel Winarske <joel.winarske at gmail.com>
>wrote:
>
>> Here is my config.  I see protocol init happen for each, but I'm not
>> seeing LWS_CALLBACK_HTTP.  If I revert to single vhost, many mounts -
>init,
>> and LWS_CALLBACK_HTTP happen.  Albeit I can't differentiate what is
>what.
>>
>> {
>>  "vhosts": [{
>>      "name": "localhost",
>>      "port": "7681",
>>      "mounts": [{
>>          "mountpoint": "/ui",
>>          "origin": "file://c:/etc/lwsws/www",
>>          "default": "index.html",
>>          "cache-max-age": "60",
>>          "cache-reuse": "1",
>>          "cache-revalidate": "1",
>>          "cache-intermediaries": "0",
>>      "extra-mimetypes": {
>>          ".hbs": "text/x-handlebars-template",
>>  ".json": "text/json"
>>      }
>>  }]
>>  }, {
>>      "name": "fileCount",
>>      "port": "7681",
>>      "mounts": [{
>>        "mountpoint": "/ui/fileCount",
>>        "origin": "callback://cmd-protocol"
>>  }],
>>        "ws-protocols": [{
>>      "cmd-protocol": {
>>       "api" : "3",
>>        "status": "ok"
>>      }
>>        }]
>>      }, {
>>      "name": "prop",
>>      "port": "7681",
>>      "mounts": [{
>>        "mountpoint": "/prop",
>>        "origin": "callback://cmd-protocol"
>>  }],
>>        "ws-protocols": [{
>>      "cmd-protocol": {
>>       "api" : "1",
>>        "status": "ok"
>>      }
>>        }]
>>      }, {
>>      "name": "sys",
>>      "port": "7681",
>>      "mounts": [{
>>        "mountpoint": "/sys",
>>        "origin": "callback://cmd-protocol"
>>  }],
>>        "ws-protocols": [{
>>      "cmd-protocol": {
>>       "api" : "2",
>>        "status": "ok"
>>      }
>>        }]
>>      }, {
>>     "name": "rest",
>>      "port": "7681",
>>      "mounts": [{
>>        "mountpoint": "/rest",
>>        "origin": "callback://cmd-protocol"
>>  }],
>>        "ws-protocols": [{
>>      "cmd-protocol": {
>>       "api" : "4",
>>        "status": "ok"
>>      }
>>        }]
>>      }
>>   ]
>> }
>>
>> Something else odd I am seeing, I have no valid WS protocols defined,
>yet
>> the server accepts all client WS requests and indicates it's switched
>> protocols.  Am I missing something here?
>>
>>
>>    1. Request URL:
>>    ws://localhost:7681/activation
>>    2. Request Method:
>>    GET
>>    3. Status Code:
>>    101 Switching Protocols
>>
>>
>> On Wed, Feb 1, 2017 at 10:30 PM, Andy Green <andy at warmcat.com> wrote:
>>
>>>
>>>
>>> On 02/02/2017 02:17 PM, Joel Winarske wrote:
>>>
>>>> Say I want to implement a single plugin for multiple mount points. 
>In
>>>> the protocol callback, how do I get the mount point string value? 
>Do I
>>>> have to examine the header, or is it already available somewhere?
>>>>
>>>
>>> The right way to look at it is you created a plugin with a single
>>> protocol.
>>>
>>> It happened that multiple mountpoints, usually on a different vhost
>each
>>> time, wanted to mount an instance of that protocol somewhere in
>their URL
>>> space.
>>>
>>> As far as that goes, in itself the protocol callback is not aware of
>the
>>> mountpoint, and the mounts are all treated the same, although you
>can use
>>> per-vhost structs in the callback to mean that mounted protocol
>instances
>>> on each vhost can do things separately.
>>>
>>> To make things more useful, you can pass in "pvo", per-vhost options
>when
>>> you enable the protocol for each vhost individually.  For example
>the
>>> server-status URL I sent before has its protocol enabled like this
>>>
>>>        "lws-server-status": {
>>>          "status": "ok",
>>>          "update-ms": "5000",
>>>          "filepath": "/sys/class/thermal/thermal_zone0/temp",
>>>          "filepath": "/proc/version",
>>>          "hide-vhosts": "1"
>>>         },
>>>
>>> So you could just as easily enable the protocol on another vhost,
>but
>>> with different settings.
>>>
>>> There are also "pmo", per-mount options the plugin can access.  But
>pvo
>>> are probably want you want if each mount is on a different vhost.
>>>
>>> You can see how the server status plugin gets ahold of the pvo at
>init
>>>
>>> https://github.com/warmcat/libwebsockets/blob/master/plugins
>>> /protocol_lws_server_status.c
>>>
>>> since he stashes them in his per-vhost struct, he can act completely
>>> differently simultaneously depndning on the vhost you access him
>from.
>>>
>>> -Andy
>>>
>>>
>>>> Thanks!
>>>>
>>>>
>>>> _______________________________________________
>>>> Libwebsockets mailing list
>>>> Libwebsockets at ml.libwebsockets.org
>>>> https://libwebsockets.org/mailman/listinfo/libwebsockets
>>>>
>>>
>>>
>>



More information about the Libwebsockets mailing list