[Libwebsockets] Unable to communicate with node server over Websocket

sthustfo sthustfo at gmail.com
Tue Aug 5 15:01:35 CEST 2014


Andy,

Thanks for the suggestions. I did try putting one protocol structure, and I
see the earlier behavior which is parsing error. I will keep looking into
this. Meanwhile, I found a node.js and socket.io based server hosted online
- appolo-chat-example.herokuapp.com/.

I was able to capture the ws handshake messages using chrome.


   1. Request URL:
   ws://
   appolo-chat-example.herokuapp.com/socket.io/?EIO=2&transport=websocket&sid=DSqTKgIc-CNbawicAAAB
   2. Request Method:
   GET
   3. Status Code:
   101 Switching Protocols
   4. Request Headers
      1.
      Provisional headers are shown
      2. Cache-Control:
      no-cache
      3. Connection:
      Upgrade
      4. Cookie:
      io=DSqTKgIc-CNbawicAAAB
      5. Host:
      appolo-chat-example.herokuapp.com
      6. Origin:
      http://appolo-chat-example.herokuapp.com
      7. Pragma:
      no-cache
      8. Sec-WebSocket-Extensions:
      permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
      9. Sec-WebSocket-Key:
      SR0i9G/oRJdJSgAXjo5iOw==
      10. Sec-WebSocket-Version:
      13
      11. Upgrade:
      websocket
      12. User-Agent:
      Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko)
      Chrome/36.0.1985.125 Safari/537.36
      5. Query String Parametersview sourceview URL encoded
      1. EIO:
      2
      2. transport:
      websocket
      3. sid:
      DSqTKgIc-CNbawicAAAB
      6. Response Headers
      1. Connection:
      Upgrade
      2. Sec-Websocket-Accept:
      dWoZ+rfisaRB50AzubuYJhd9FBk=
      3. Upgrade:
      websocket
      4. Via:
      1.1 vegur


-
sthustfo


On Tue, Aug 5, 2014 at 5:08 PM, Andy Green <andy at warmcat.com> wrote:

>
>
> On 5 August 2014 19:25:11 GMT+08:00, sthustfo <sthustfo at gmail.com> wrote:
> >Hi Andy,
> >
> >Is there a way to supress the protocols altogether? I tried to set the
> >"*info.protocols
> >= NULL"* and forced use_ssl=0 when creating the context using
> >libwebsocket_create_context() but the program encounters a SIGSEGV
> >during
> > lws_context_init_client_ssl().
> >
> >Is there a way to just not send any protocols (they are optional?) and
> >use
> >pure ws://?
>
> No, although you can negotiate with no protocol in the upgrade, in lws the
> logical protocols contain the binding to the user callback, and the first
> protocol is targeted for HTTP callbacks.
>
> So logical callbacks themselves are not optional in lws and you have to
> give at least one when creating the context.
>
> However for client, you can give NULL as the protcol you're asking for in
> libwebsocket_create_client() and he will upgrade with no protocol header.
>
> Similarly in server, you may create a protocol struct whose name is NULL,
> he will match for no protocol header in the client upgrade.
>
> So you can do what you want later, but in all cases must give at least one
> protocol struct to the context so you can get any callbacks.
>
> -Andy
>
> >
> >Thanks.
> >sthustfo
> >
> >
> >
> >On Tue, Aug 5, 2014 at 4:11 PM, Andy Green <andy at warmcat.com> wrote:
> >
> >>
> >>
> >> On 5 August 2014 18:07:09 GMT+08:00, sthustfo <sthustfo at gmail.com>
> >wrote:
> >> >Hey Andy,
> >> >
> >> >Thanks for the quick response. I am not aware of the compliance
> >status
> >> >of
> >> >socket.io but am trying to find out the same. Meanwhile, here is the
> >> >client
> >> >log with debug level 1023.
> >>
> >> It seems to send us junk (|)
> >>
> >> [411975:0442] CLIENT: nonblocking connect retry
> >> [411975:0442] CLIENT: libwebsocket_client_connect_2
> >> [411975:0442] CLIENT: libwebsocket_client_connect_2: address
> >127.0.0.1
> >> [411975:0442] CLIENT: connected
> >> [411975:0473] PARSER: WSI_TOKEN_NAME_PART '|'
> >> [411975:0473] INFO: Unknown method - dropping
> >> [411975:0474] WARN: problems parsing header
> >> [411975:0474] INFO: closing connection at LWS_CONNMODE...SERVER_REPLY
> >>
> >> If you didn't tell your server to support the protocols the test
> >clients
> >> uses, you wouldn't get any success anyway.  But it should just close
> >the
> >> connection not send junk.
> >>
> >> If you want to look further into it send the packet traces but I
> >guess it
> >> only supports some older RFC version of websockets.  Which is
> >probably a
> >> sign it's long unmaintained.
> >>
> >> -Andy
> >>
> >> >-
> >> >sthustfo
> >> >
> >> >On Tue, Aug 5, 2014 at 3:29 PM, Andy Green <andy at warmcat.com> wrote:
> >> >
> >> >>
> >> >>
> >> >> >
> >> >> >test at devpc:~/libwebsockets/build/bin$ ./libwebsockets-test-client
> >> >> >127.0.0.1
> >> >> >--port=8888
> >> >>
> >> >> Turn up the logging with -d 1023 or so
> >> >>
> >> >> >libwebsockets test client
> >> >> >(C) Copyright 2010-2013 Andy Green <andy at warmcat.com> licensed
> >under
> >> >> >LGPL2.1
> >> >> >[1457:9886] NOTICE: Initial logging level 7
> >> >> >[1457:9886] NOTICE: Library version: 1.3 67f9459
> >> >> >[1457:9887] NOTICE: IPV6 compiled in and enabled
> >> >> >[1457:9887] NOTICE: libev support not compiled in
> >> >> >[1457:9889] NOTICE:  static allocation: 4472 + (12 x 1024 fds) =
> >> >16760
> >> >> >bytes
> >> >> >[1457:9890] NOTICE:  canonical_hostname = pk-laptop
> >> >> >[1457:9890] NOTICE:  per-conn mem: 128 + 1594 headers + protocol
> >rx
> >> >buf
> >> >> >Waiting for connect...
> >> >> >[1457:9932] WARN: problems parsing header
> >> >> >Exiting
> >> >> >[1457:9933] NOTICE: libwebsocket_context_destroy
> >> >> >
> >> >> >And on the node server, I see the following log
> >> >> >
> >> >> >test at devpc:~/node$ DEBUG=* node basic.js
> >> >> >   info  - socket.io started
> >> >> >   debug - destroying non-socket.io upgrade
> >> >> >   debug - destroying non-socket.io upgrade
> >> >>
> >> >> Is socket.io compliant with the actual websockets standard or some
> >> >older
> >> >> RFC?
> >> >>
> >> >> It seems it can't parse our upgrade request (which does pretty
> >good
> >> >at
> >> >> being compliant with everything else).
> >> >>
> >> >> -Andy
> >> >>
> >> >>
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20140805/45335761/attachment-0001.html>


More information about the Libwebsockets mailing list