Need help understanding a few things in general

[stozk]

Hi,

I'm trying to create a client with this library to connect to a websocket server, which is implemented in Java/Spring using sockJS. But I would like to clear some things up for my understanding

When I use the sockJS client for nodeJS (nodejs-client) and look at what happens with wireshark, I'll get this for example, when I provide the server address http:localhost:8085/websocket/data

GET /websocket/data/info HTTP/1.1 So the sockJS client lib appends that /info path. After that I get a HTTP/1.1 200 OK (application/json) with a payload like this:

JavaScript Object Notation: application/json Object Member Key: entropy Number value: -1052781070 Key: entropy Member Key: origins Array Key: origins Member Key: cookie_needed True value Key: cookie_needed Member Key: websocket True value Key: websocket

After that the sockjs-client does this: GET /websocket/data/820/miv2llpp/websocket HTTP/1.1 (I have omitted the rest because it looks like the regular connection upgrade message) Which results in: HTTP/1.1 101 Switching Protocols And the websocket connection is properly established.

I tried to adapt the test client example with the dumb_increment_protocol from the libwebsockets example and when I provide http:localhost:8085/websocket/data as an argument to it, the initial HTTP request will go to:

GET /websocket/data HTTP/1.1 No "/info" gets appended, a connection will open and I get a response: HTTP/1.1 200 OK (text/plain) With the message "welcome to SockJS!\n" And nothing happens after that.

When I provide http:localhost:8085/websocket/data/info as an argument, I'll get the HTTP/1.1 200 OK (application/json) response just like with the sockJS client with the above mentioned json message, but after that nothing happens.

So essentially my questions are: Do I have to manually implement the steps in my protocol in libwebsockets to send the upgrade message? Do I just randomly generate the "GET /websocket/data/820/miv2llpp/websocket HTTP/1.1" path or is there something I have to pull it from (also the Sec-WebSocket-Key)?

I tried to look into different client implementations (also python clients for example), but there it looks like people are just building the path by concatenating a randomly generated uuid1 etc.

BR Daniel

[lws-team]

Well, none of this additional stuff is in RFC6455 (websockets) so it is not supported in lws.

If I understood it, it's basically doing two HTTP GETs, one passes this JSON content and the other does the upgrade to ws. Is the ws upgrade using a token from the JSON that came first? Acting like a cookie maybe? In that case you can do it with two client connections in lws, parsing the JSON inbetween.

If not you'll have to find out what the story is from somewhere else, this is specific to that server's way of doing things and not a legitimate "websocket thing".

[stozk]

Yeah that's what I tried to understand how that machanism works there... but their readme says:

https://github.com/sockjs/sockjs-client

Connecting to SockJS without the client

Although the main point of SockJS is to enable browser-to-server connectivity, it is possible to connect to SockJS from an external application. Any SockJS server complying with 0.3 protocol does support a raw WebSocket url. The raw WebSocket url for the test server looks like:

ws://localhost:8081/echo/websocket You can connect any WebSocket RFC 6455 compliant WebSocket client to this url. This can be a command line client, external application, third party code or even a browser (though I don't know why you would want to do so).

So that means, that libwebsocket should work out of the box with sockJS I guess (Altough I haven'T managed to make it work yet). I only get a "connection" when I use the actual endpoint or with the appended /info path.

I don't understand if the path "echo" in "...:8081/echo/websocket" is the equivalent to my "...:8085/websocket/data/websocket"

[lws-team]

Right, we claim to be RFC6455 compliant.

It looks like the "/echo" is an application / protocol-specific path.

What I would do is turn up logging to -d63 or so (this requires building in DEBUG mode, cmake .. -DCMAKE_BUILD_TYPE=DEBUG) and study what actually happens when you touch a URL that they say is RFC6455 compliant. But the 'echo' bit suggests you also have to configure a protocol on the server side to get anywhere.

[stozk]

It looks like it was a layer 8 problem, I have used http://localhost:8085/websocket/data as the input argument for the program, which gets parsed by the uri parser. When I use ws://localhost:8085/websocket/data the connection is properly established.

I didn't think about that because the other clients I normally use for WS (java/nodejs) handle both formats equally.