[Libwebsockets] http client callback owner

Joel Winarske joel.winarske at gmail.com
Tue Apr 25 02:21:58 CEST 2017


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

On Mon, Apr 24, 2017 at 4:30 PM, Andy Green <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>> 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.
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20170424/c08b6d9d/attachment-0002.html>


More information about the Libwebsockets mailing list