[Libwebsockets] http client callback owner

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



On 04/25/2017 08:35 AM, Andy Green wrote:
>
>
> 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
>
> https://github.com/warmcat/libwebsockets/blob/master/test-server/test-server-v2.0.c#L147 
>
>
> Using the JSON config, as told in README.lwsws.md it's like
>
> |"ws-protocols": [{ "warmcat-timezoom": { "status": "ok", "default": 
> "1" } }]|
>
>

Mmm sorry that is correct, but it mixes up the story for client and server.

For client at the point when it sees no protocol header came back from 
the server

     len = lws_hdr_total_length(wsi, WSI_TOKEN_PROTOCOL);
     if (!len) {
         lwsl_info("lws_client_int_s_hs: WSI_TOKEN_PROTOCOL is null\n");
         /*
          * no protocol name to work from,
          * default to first protocol
          */
         n = 0;
         wsi->protocol = &wsi->vhost->protocols[0];
         goto check_extensions;
     }

so it's as you say, it forces it to protocols[0] of the vhost for client 
NULL protocol case.  There aren't any arrangements for changing that atm.

-Andy

> -Andy
>
>>
>> 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.
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets




More information about the Libwebsockets mailing list