[Libwebsockets] http client callback owner

Andy Green andy at warmcat.com
Tue Apr 25 02:35:44 CEST 2017

On 04/25/2017 08:21 AM, Joel Winarske wrote:
> To clarify.  In the case where the client proposes multiple protocols, 
> and the server responds with one:  On the client side there would need 
> to be a defined callback for each proposed protocol, or it goes to the 
> default HTTP handler (effectively the bit bucket).  Correct?  If this 
> is the case, I was just confused, and am much better now ;)

The client is the guy that initially proposes the protocol[s], so he 
wouldn't propose anything he didn't know how to deal with / have a 
callback for.

In the case that he did not propose any protocol, the server assumes 
it's implicitly the default protocol for that vhost, and carries on with 
the ws handshake without sending a protocol header either.  In that 
case, by default, its protocols[0] that is assumed to be selected on the 
client side.  But, you can control which protocol actually handles these 
NULL protocol situations using a per-vhost option


Using the JSON config, as told in README.lwsws.md it's like

|"ws-protocols": [{ "warmcat-timezoom": { "status": "ok", "default": "1" 
} }]|


> On Mon, Apr 24, 2017 at 4:30 PM, Andy Green <andy at warmcat.com 
> <mailto:andy at warmcat.com>> wrote:
>     On 04/25/2017 07:22 AM, Joel Winarske wrote:
>         Hmm.  So if the server the http client is connecting to, does
>         not response with a sec-websocket-protocol header it gets
>         handled by the default handler?
>     If the client sent the protocol header, the server must reply with
>     one.  So at that point the ws client is hearing about the selected
>     ws protocol for the first time, until then there was no active
>     protocol (if not ws but http, by contrast we set the protocol to
>     the one given in the connect info almost immediately).
>     Don't forget the idea of this in the ws RFC is the ws client may
>     propose n protocols (eg, xxx_v1, xxx_v2) and the server selects
>     exactly one and returns it, only at that point does the ws client
>     know what it's supposed to be talking on the ws link.  (again
>     different from the lws client http[s] behaviour where they are not
>     going to negotiate it).
>         In the case where the server requires a specific protocol
>         value, you need to name your plugin that of the server
>         protocol you wish to connect to?
>     I'm not unwilling to decouple them if there's a reason and I can
>     understand what it's supposed to do ^^  Right now I still don't
>     understand what you want it to do.
>     -Andy
>         On Mon, Apr 24, 2017 at 3:57 PM, Andy Green <andy at warmcat.com
>         <mailto:andy at warmcat.com> <mailto:andy at warmcat.com
>         <mailto:andy at warmcat.com>>> wrote:
>             On 04/25/2017 04:33 AM, Joel Winarske wrote:
>                 Yes.  I'm up to eleven mount points, and nine plugins.
>         Three
>                 mount points call the same plugin which handles the
>         HTTP stuff.
>                 In the case of the scenario in this thread, my design
>                 requirement is to proxy a WS -> WSS connection through
>         lwsws.         It all works short of lwsws passing an invalid
>         sec-protocol
>                 header to the far end server.  I hacked up the http client
>                 connect to suppress sending sec-protocol in case of a
>         WS/WSS
>                 http client.
>             Hum OK.
>             But you are asking for two separate protocol names.  I
>         took a look
>             at the code, I can see how to kind of do this but I am stuck
>             because I don't really understand what behaviour you want
>         from it.
>             For example it looks like it might be enough to allow setting
>             stash->protocol to something else in
>             lws_client_connect_via_info(), after using the existing
>         name to
>             set the protocol.  stash->protocol controls what is sent
>         to the
>             server if anything.  But then what is it you want it to do
>         when
>             the ws response comes back from the server accepting that
>             protocol? Switch to it, keep the original one... something
>         else?
>                 In the case of all the JS WS code I've seen, it suppresses
>                 sending the protocol header unless you specify the
>         protocol
>                 name as the second parameter to the WS constructor.
>             That is correct.  But "no protocol" is a degenerate case
>         for ws,
>             there can only be one "no protocol" ws offering per vhost.  So
>             unless it's a trivial example it's usually not the right
>         thing.
>             -Andy
>                 On Sun, Apr 23, 2017 at 4:54 PM, Andy Green
>         <andy at warmcat.com <mailto:andy at warmcat.com>
>                 <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>
>         <mailto:andy at warmcat.com <mailto:andy at warmcat.com>
>                 <mailto:andy at warmcat.com <mailto:andy at warmcat.com>>>>
>         wrote:
>                     On 24 April 2017 05:33:16 GMT+08:00, Joel Winarske
>                     <joel.winarske at gmail.com
>         <mailto:joel.winarske at gmail.com>
>         <mailto:joel.winarske at gmail.com <mailto:joel.winarske at gmail.com>>
>                 <mailto:joel.winarske at gmail.com
>         <mailto:joel.winarske at gmail.com>
>                 <mailto:joel.winarske at gmail.com
>         <mailto:joel.winarske at gmail.com>>>> wrote:
>                     >>
>                     >> Why?  Just this --->?
>                     >>
>                     >
>                     >
>                     >I think there should be two unique protocol
>         members for
>                 http client
>                     >info:
>                     >1.  server protocol.  The "Server" side WS protocol
>                 name.  Used
>                     as the
>                     >value for the "sec-protocol" header.
>                     >2.  callback protocol.  The name of the protocol
>         plug-in
>                 which
>                     handles
>                     >the
>                     >http client callbacks.
>                     >
>                     >I'm running into cases where they are not the
>         same value.
>                     >
>                     >Renaming the plugin protocol to match the server
>         isn't a
>                 great
>                     option.
>                     Does it help to point out you can associate part
>         or all of a
>                     vhost's URL space with a protocol using mounts?
>                     There is a CALLBACK mount type that directs the
>         http stuff
>                 to the
>                     protocol handler named in the origin part of the
>         mount.         In the
>                     JSON config it's like this in the mount definition
>                     "origin": "callback://protocol-lws-messageboard",
>                     This gives you a lot more flexibility in terms of
>         supporting
>                     multiple things in one vhost at different URLs.
>                     -Andy
>                     --
>                     Sent from my Android device with K-9 Mail. Please
>         excuse
>                 my brevity.

More information about the Libwebsockets mailing list