[Libwebsockets] Q on protocol names

Michael Haberler mail17 at mah.priv.at
Sun Aug 10 15:06:44 CEST 2014


Am 10.08.2014 um 04:01 schrieb Andy Green <andy at warmcat.com>:

> 
> 
> On 10 August 2014 04:36:42 GMT+08:00, Michael Haberler <mail17 at mah.priv.at> wrote:
>> 
>> I'd like to have a single protocols structure, since I have a single
>> callback only anyway, which cover http/s and ws/s
>> 
>> Ideally I'd inspect the ws protcol name the client desired, and upgrade
>> to _that_ protocol, set an option in my private session structure (or
>> deny altogether, modulo on protocol name)
>> 
>> is that something I could do? how?
> 
> I'll study your patch for it, but is this actually something that needs doing with dynamic protocol names in the user code?

In principle you're right, but making protocols dynamically allocated would be a big bite to swallow given the current libwebsocket_protocols data structure. And I think in most cases that is not needed.

In practice, it's more likely you have rather similar protocols - maybe just distinguished by version numbers (for example, karlp's requirement in #147).

the idea here is - instead of enumerating every possible protocol name hard-coded in additional libwebsocket_protocols structs, provide a hook and let user code decide which proto to support and how; that's what #158 does (besides giving the right answer in Sec-WebSocket-Protocol: ).

> I don't know what your use-case is but don't forget there is a URL part also coming with the ws upgrade action, that can be used to refine the meaning of that websocket connection.

yes, and I use that already for other options unrelated to ws protocol, but that cannot sensibly handle existing client code which offers say several protocol versions and lets the server pick one. That code would have to be rewritten to pass that information in the URI, and server-side code to pick out that information from the URI. That being doable in the general case is a major assumption to make; it impacts stock js library use substantially - for instance, karlp would have to massage the URI when using mqttws31.js.

> Because protocols themselves mandate specific code support that either exists in the server / client or not, handling them as static definitions seems more natural...

that's generally an ok assumption. The way I deal with the variants/version issue is: I parse the protocol names list in FILTER_PROTOCOL_CONNECTION, decide which one to use, record that in my private session structure, and let the library know of that by calling libwebsocket_set_protocol(wsi,name, <opt proto if not default>).

- Michael




More information about the Libwebsockets mailing list