Allow different suffixes for websockets and HTTP connections

[viet-trinh-stonex]

Currently, all Websockets and HTTP connections use the lightstreamer url suffix. I would like to be able to set the HTTP connections to use another suffix. different than the WebSocket suffix.

The reason is I have an API gateway (Azure) that require websockets have their own suffix unique from any HTTP suffixes.

Example currently implemented:
wss://some-domain/lightstreamer
https://some-domain/lightstreamer/create_session.txt?LS_protocol=TLCP-2.1.0

Requested feature:
client.setHttpSuffix('lightstreamer-http')

So these would be the new urls:
wss://some-domain/lightstreamer
https://some-domain/lightstreamer-http/create_session.txt?LS_protocol=TLCP-2.1.0

• API gateway can re-write the url to be lightstreamer/create_session.txt?LS_protocol=TLCP-2.1.0

[dario-weswit]

Obviously you can overcome any library limitation through a local branch.
Thinking at the proposed method as part of the public interface, it seems quite a tricky setting, that would make sense only to address a common issue.
Do you confirm that your API gateway requires that websocket connections are detected and treated separately from http requests even if the target host is the same for both?
If you just don't provide this information and have the gateway treat everything as http, would the websocket connections not work or not scale?
May you please point us to any page in the Azure documentation that could help us understand the details of this limitation?

[viet-trinh-stonex]

I confirmed that websockets has to be registered as a websocket which handles the http upgrade.

If your lightstreamer address was something like: wss://some-domain/lightstreamer/websocket it would work, it's because the websocket address is the prefix of the http addresses.

Here is the Azure documentation: https://docs.microsoft.com/en-us/azure/api-management/websocket-api

[dario-weswit]

Thank you for the information.
So, Azure API Gateway wants to identify websocket upgrade requests in order to handle the websocket flow in a dedicated way and it wants to identify these upgrade requests with no effort, based on the url path.
Moreover, if I understand correctly, even though the websocket path "/lightstreamer" is a subpath of the http path (all of the form "/lightstreamer/*.txt"), this is not enough for the API gateway to distinguish the cases.
This seems to really account for a SDK interface extension which provides this differentiation.
We need to think about the exact way to extend the public interface and will let you know as soon as possible.

What can you do as a workaround in the meantime?
You would need to clone the project and manually change the library code, but we need to devise the simplest possible change.
One idea could be the following:

1. Modify, in your application code, the creation of LightstreamerClient by adding a url prefix. For instance, instead of "https://ls.mysite.com" you could pass "https://ls.mysite.com/lightstreamer-http". Note that, as a consequence, the library would use the "/lightstreamer-http/lightstreamer" path for both http and websocket.
2. Modify the javascript client library code that opens a websocket in order to strip the "lightstreamer-http/" part from the url to be used. It should be enough to do it in the "getWebSocket" function of the WebSocketConnector" class. At this point, the websocket requests will get back to using "/lightstreamer" and will be differentiated from http requests.
3. Configure your API Gateway to forward http requests to the Server by stripping off the "lightstreamer-http/" part. Hence the Server will receive all requests in the expected way.

[viet-trinh-stonex]

Hi, my temporary solution is to intercept the XMLHttpRequest.prototype.open method to update the http requests with the correct prefix.

[dario-weswit]

Hi, thank you for the update.
This is indeed a very lightweight solution.
We confirm that all http requests from our library pass from there.
This will allow us to setup an explicit mechanism and the related interface extension only in the forthcoming release 9 of the library.