[Libwebsockets] http client callback owner

Andy Green andy at warmcat.com
Sun Apr 23 22:57:29 CEST 2017

On April 24, 2017 4:30:33 AM GMT+08:00, Joel Winarske <joel.winarske at gmail.com> wrote:
>I noticed that when initiating a connection to ws or wss, it will use
>"protocol" value for the "sec-protocol" header.  So if my local lwsws


>protocol is named "xyz", and I set protocol to "xyz" as I want to own
>http client callbacks in my plug-in, when I connect to the ws/wss
>it will send the "sec-protocol" value of "xyz".  The protocol handler


>actual protocol name for far end connect should be different.  If

Why?  Just this --->?

>is null, then I would expect "sec-protocol" not to be added to the
>headers.  What do you think?

Lws indeed doesn't generate sec-protocol if the protocol name is NULL.  But a vhost like that can only serve one ws protocol.  If you update the protocol later, existing clients will break if it's a breaking change or updated clients must be told to go to a new vhost.

If you really have to do that, we can elect a special char like # at the start of the protocol name to indicate it should not be sent.  But it's better to use a server capable of understanding ws protocol names...


>On Sat, Apr 22, 2017 at 4:20 PM, Andy Green <andy at warmcat.com> wrote:
>> On 04/23/2017 06:20 AM, Joel Winarske wrote:
>>> Do the CLIENT callbacks only happen on protocol index 0, or do they
>>> happen on which ever protocol the client was initiated from? 
>Meaning do I
>>> get a separate client handler per protocol, or just the global
>handler via
>>> protocol 0?  I've only had a need to use the global scheme via
>protocol 0,
>>> until now.
>> Since the last few weeks on master very early in the client
>> process the client wsi gets its protocol pointer set to the vhost
>> of the named protocol given in the client connection info.  So since
>> even things like CONNECTION_ERROR are targeted at the vhost instance
>of the
>> named protocol.
>> The reason is I had a use myself for client stuff selfcontained in
>> context of a "plugin" for ESP32 Over The Air update support... it
>> clear then everything should be called back into the plugin for
>> too...
>> https://github.com/warmcat/libwebsockets/blob/master/plugins
>> /protocol_esp32_lws_scan.c
>> -Andy
>>> -Joel
>>> _______________________________________________
>>> Libwebsockets mailing list
>>> Libwebsockets at ml.libwebsockets.org
>>> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list