[Libwebsockets] protocol plugin

Joel Winarske joel.winarske at gmail.com
Fri Feb 10 04:21:42 CET 2017


I see the protocol value set.  That may come in handy.


On Thu, Feb 9, 2017 at 5:58 PM Andy Green <andy at warmcat.com> wrote:

>
>
> On 02/10/2017 08:32 AM, Joel Winarske wrote:
> > The test-client case behaves the same with
> > "wss://localhost:7681/activation?encoding=text" or just
> > "wss://localhost:7681/activation"
>
> I tried it on ws:// so I could look at it
>
> 09:57:17.676603 IP localhost.47005 > localhost.7681: Flags [P.], seq
> 1:361, ack 1, win 342, options [nop,nop,TS val 1160891244 ecr
> 1160891244], length 360
>          0x0000:  4500 019c 3582 4000 4006 05d8 7f00 0001 E...5. at .@.......
>          0x0010:  7f00 0001 b79d 1e01 42c8 feed 7c8f 0a4b ........B...|..K
>          0x0020:  8018 0156 ff90 0000 0101 080a 4531 cb6c ...V........E1.l
>          0x0030:  4531 cb6c 4745 5420 2f61 6374 6976 6174 E1.lGET./activat
>          0x0040:  696f 6e3f 656e 636f 6469 6e67 3d74 6578 ion?encoding=tex
>          0x0050:  7420 4854 5450 2f31 2e31 0d0a 5072 6167 t.HTTP/1.1..Prag
>          0x0060:  6d61 3a20 6e6f 2d63 6163 6865 0d0a 4361 ma:.no-cache..Ca
>          0x0070:  6368 652d 436f 6e74 726f 6c3a 206e 6f2d che-Control:.no-
>          0x0080:  6361 6368 650d 0a48 6f73 743a 206c 6f63 cache..Host:.loc
>          0x0090:  616c 686f 7374 0d0a 4f72 6967 696e 3a20 alhost..Origin:.
>          0x00a0:  6874 7470 3a2f 2f6c 6f63 616c 686f 7374 http://localhost
>          0x00b0:  0d0a 5570 6772 6164 653a 2077 6562 736f ..Upgrade:.webso
>          0x00c0:  636b 6574 0d0a 436f 6e6e 6563 7469 6f6e cket..Connection
>          0x00d0:  3a20 5570 6772 6164 650d 0a53 6563 2d57 :.Upgrade..Sec-W
>          0x00e0:  6562 536f 636b 6574 2d4b 6579 3a20 4b41 ebSocket-Key:.KA
>          0x00f0:  4d46 5838 7535 556c 5932 5542 6b4f 5376 MFX8u5UlY2UBkOSv
>          0x0100:  5577 3041 3d3d 0d0a 5365 632d 5765 6253 Uw0A==..Sec-WebS
>          0x0110:  6f63 6b65 742d 5072 6f74 6f63 6f6c 3a20 ocket-Protocol:.
>          0x0120:  6475 6d62 2d69 6e63 7265 6d65 6e74 2d70 dumb-increment-p
>          0x0130:  726f 746f 636f 6c0d 0a53 6563 2d57 6562 rotocol..Sec-Web
>          0x0140:  536f 636b 6574 2d45 7874 656e 7369 6f6e Socket-Extension
>          0x0150:  733a 2070 6572 6d65 7373 6167 652d 6465 s:.permessage-de
>          0x0160:  666c 6174 653b 2063 6c69 656e 745f 6d61 flate;.client_ma
>          0x0170:  785f 7769 6e64 6f77 5f62 6974 730d 0a53 x_window_bits..S
>          0x0180:  6563 2d57 6562 536f 636b 6574 2d56 6572 ec-WebSocket-Ver
>          0x0190:  7369 6f6e 3a20 3133 0d0a 0d0a sion:.13....
>
> seems OK.
>
> -Andy
>
> >
> >
> > On Thu, Feb 9, 2017 at 4:06 PM, Joel Winarske <joel.winarske at gmail.com
> > <mailto:joel.winarske at gmail.com>> wrote:
> >
> >     Using - http://www.websocket.org/echo.html
> >     <http://www.websocket.org/echo.html> to test:
> >
> >     In wireshark I see:
> >      160.690778127.0.0.1127.0.0.1HTTP1128GET /activation?encoding=text
> >     HTTP/1.1
> >      180.691789127.0.0.1127.0.0.1HTTP434HTTP/1.1 101 Switching Protocols
> >     packets from client to server
> >     <no response from my protocol plugin>
> >     close from client
> >     close response from server
> >
> >     In the log I see:
> >     [2017/02/09 15:04:57:8757] NOTICE: Creating Vhost '127.0.0.1' port
> >     7681, 3 protocols, IPv6 off
> >     [2017/02/09 15:04:57:8767] NOTICE:    mounting
> >     callback://activation-protocol to /activation
> >     ...
> >     [2017/02/09 15:04:57:8777] NOTICE:  Using non-SSL mode
> >     [2017/02/09 15:04:57:8817] NOTICE:     vh 127.0.0.1 prot
> >     cmd-protocol opt status
> >     [2017/02/09 15:04:57:8817] NOTICE:     vh 127.0.0.1 prot
> >     activation-protocol opt status
> >     [2017/02/09 15:04:57:8827] NOTICE: activate:
> >     LWS_CALLBACK_PROTOCOL_INIT
> >     [2017/02/09 15:05:15:6913] NOTICE: Accepted wsi 002C3FC8 to
> >     context 0020A890, tsi 0
> >     [2017/02/09 15:06:02:7518] NOTICE: Accepted wsi 022C5100 to
> >     context 0020A890, tsi 0
> >
> >     But when I send data from the websocket.org <http://websocket.org>
> >     site, I never see the callback happen.  Not
> >     even LWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED.
> >
> >     It would seem the server is consuming the WS data packet, and not
> >     making the callback.  What am I missing?
> >
> >     In addition - when I select an unknown WS "mount", such as
> >     "ws://localhost:7681/install", I get the identical behavior.
> >
> >     Switching the vhosts name to "127.0.0.1", has no impact.
> >
> >     When I use the test-client to test, I do see
> >     LWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED as expected, but
> >     it ends with "CLIENT_CONNECTION_ERROR: dumb: (null)", after which
> >     I see the WebSocket Close packet on the wire.  I instrumented what
> >     you checked in yesterday.
> >
> >     [2017/02/09 16:03:26:0400] NOTICE: dumb: connecting
> >     [2017/02/09 16:03:26:0410] ERR: getaddrinfo localhost -> 127.0.0.1
> >     [2017/02/09 16:03:26:0544] ERR: getaddrinfo localhost -> 127.0.0.1
> >     [2017/02/09 16:03:26:0544] NOTICE: dumb:
> >     LWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED [permessage-deflate]
> >     [2017/02/09 16:03:26:0544] NOTICE: dumb:
> >     LWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED [deflate-frame]
> >     [2017/02/09 16:03:26:0554] NOTICE: dumb:
> >     LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER
> >     [2017/02/09 16:03:26:0554] NOTICE: dumb:
> >     LWS_CALLBACK_CLIENT_CONNECTION_ERROR
> >     [2017/02/09 16:03:26:0564] ERR: CLIENT_CONNECTION_ERROR: dumb: (null)
> >
> >     My current config:
> >     {
> >      "vhosts": [{
> >          "name": "localhost",
> >          "port": "7681",
> >          "mounts": [{
> >            "mountpoint": "/activation",
> >            "origin": "callback://activation-protocol"
> >     },{
> >              "mountpoint": "/",
> >              "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",
> >         }
> >     },{
> >            "mountpoint": "/sys",
> >            "origin": "callback://cmd-protocol",
> >       "pmo":[{"api":"2"}]
> >     },{
> >            "mountpoint": "/ui/fileCount",
> >            "origin": "callback://cmd-protocol",
> >       "pmo":[{"api":"3"}]
> >     },{
> >            "mountpoint": "/prop",
> >            "origin": "callback://cmd-protocol",
> >       "pmo":[{"api":"1"}]
> >     }],
> >          "ws-protocols": [{
> >              "activation-protocol": {
> >     "status": "ok"
> >     },
> >     "cmd-protocol": {
> >     "status": "ok"
> >     }
> >          }]
> >         }
> >       ]
> >     }
> >
> >
> >     On Sun, Feb 5, 2017 at 1:14 PM, Andy Green <andy at warmcat.com
> >     <mailto:andy at warmcat.com>> wrote:
> >
> >
> >
> >         On February 6, 2017 2:56:03 AM GMT+08:00, Joel Winarske
> >         <joel.winarske at gmail.com <mailto: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 <mailto: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 <mailto: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
> >         <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
> >         <mailto:Libwebsockets at ml.libwebsockets.org>
> >         >>>> https://libwebsockets.org/mailman/listinfo/libwebsockets
> >         <https://libwebsockets.org/mailman/listinfo/libwebsockets>
> >         >>>>
> >         >>>
> >         >>>
> >         >>
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20170210/3fe57f70/attachment-0002.html>


More information about the Libwebsockets mailing list