[Libwebsockets] http client callback owner

Andy Green andy at warmcat.com
Tue Apr 25 01:30:50 CEST 2017



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>> 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>>> 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>>> 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