<div dir="ltr">Hi Andy,<div><br></div><div>Now able to communicate with the node server. There was a typo with the path value.</div><div><br></div><div class="gmail_extra">-</div><div class="gmail_extra">sthustfo<br><br><div class="gmail_quote">
On Tue, Aug 5, 2014 at 7:15 PM, Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
<br>
On 5 August 2014 21:01:35 GMT+08:00, sthustfo <<a href="mailto:sthustfo@gmail.com">sthustfo@gmail.com</a>> wrote:<br>
>Andy,<br>
><br>
>Thanks for the suggestions. I did try putting one protocol structure,<br>
>and I<br>
>see the earlier behavior which is parsing error. I will keep looking<br>
>into<br>
>this. Meanwhile, I found a node.js and <a href="http://socket.io" target="_blank">socket.io</a> based server hosted<br>
>online<br>
>- <a href="http://appolo-chat-example.herokuapp.com/" target="_blank">appolo-chat-example.herokuapp.com/</a>.<br>
><br>
>I was able to capture the ws handshake messages using chrome.<br>
><br>
><br>
</div>>   1. Request URL:<br>
>   ws://<br>
><a href="http://appolo-chat-example.herokuapp.com/socket.io/?EIO=2&transport=websocket&sid=DSqTKgIc-CNbawicAAAB" target="_blank">appolo-chat-example.herokuapp.com/socket.io/?EIO=2&transport=websocket&sid=DSqTKgIc-CNbawicAAAB</a><br>

>   2. Request Method:<br>
>   GET<br>
>   3. Status Code:<br>
>   101 Switching Protocols<br>
>   4. Request Headers<br>
>      1.<br>
>      Provisional headers are shown<br>
>      2. Cache-Control:<br>
>      no-cache<br>
>      3. Connection:<br>
>      Upgrade<br>
>      4. Cookie:<br>
>      io=DSqTKgIc-CNbawicAAAB<br>
>      5. Host:<br>
>      <a href="http://appolo-chat-example.herokuapp.com" target="_blank">appolo-chat-example.herokuapp.com</a><br>
>      6. Origin:<br>
>      <a href="http://appolo-chat-example.herokuapp.com" target="_blank">http://appolo-chat-example.herokuapp.com</a><br>
>      7. Pragma:<br>
>      no-cache<br>
>      8. Sec-WebSocket-Extensions:<br>
>     permessage-deflate; client_max_window_bits, x-webkit-deflate-frame<br>
>      9. Sec-WebSocket-Key:<br>
>      SR0i9G/oRJdJSgAXjo5iOw==<br>
>      10. Sec-WebSocket-Version:<br>
>      13<br>
<br>
This is the release version of the protocol.<br>
<br>
So for the version of <a href="http://socket.io" target="_blank">socket.io</a> they're using anyway, it should be compatible with lws.<br>
<br>
-Andy<br>
<br>
>      11. Upgrade:<br>
>      websocket<br>
>      12. User-Agent:<br>
<div class="">>   Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko)<br>
>      Chrome/36.0.1985.125 Safari/537.36<br>
</div>>      5. Query String Parametersview sourceview URL encoded<br>
>      1. EIO:<br>
>      2<br>
>      2. transport:<br>
>      websocket<br>
>      3. sid:<br>
>      DSqTKgIc-CNbawicAAAB<br>
>      6. Response Headers<br>
>      1. Connection:<br>
>      Upgrade<br>
>      2. Sec-Websocket-Accept:<br>
>      dWoZ+rfisaRB50AzubuYJhd9FBk=<br>
>      3. Upgrade:<br>
>      websocket<br>
>      4. Via:<br>
<div class="HOEnZb"><div class="h5">>      1.1 vegur<br>
><br>
><br>
>-<br>
>sthustfo<br>
><br>
><br>
>On Tue, Aug 5, 2014 at 5:08 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br>
><br>
>><br>
>><br>
>> On 5 August 2014 19:25:11 GMT+08:00, sthustfo <<a href="mailto:sthustfo@gmail.com">sthustfo@gmail.com</a>><br>
>wrote:<br>
>> >Hi Andy,<br>
>> ><br>
>> >Is there a way to supress the protocols altogether? I tried to set<br>
>the<br>
>> >"*info.protocols<br>
>> >= NULL"* and forced use_ssl=0 when creating the context using<br>
>> >libwebsocket_create_context() but the program encounters a SIGSEGV<br>
>> >during<br>
>> > lws_context_init_client_ssl().<br>
>> ><br>
>> >Is there a way to just not send any protocols (they are optional?)<br>
>and<br>
>> >use<br>
>> >pure ws://?<br>
>><br>
>> No, although you can negotiate with no protocol in the upgrade, in<br>
>lws the<br>
>> logical protocols contain the binding to the user callback, and the<br>
>first<br>
>> protocol is targeted for HTTP callbacks.<br>
>><br>
>> So logical callbacks themselves are not optional in lws and you have<br>
>to<br>
>> give at least one when creating the context.<br>
>><br>
>> However for client, you can give NULL as the protcol you're asking<br>
>for in<br>
>> libwebsocket_create_client() and he will upgrade with no protocol<br>
>header.<br>
>><br>
>> Similarly in server, you may create a protocol struct whose name is<br>
>NULL,<br>
>> he will match for no protocol header in the client upgrade.<br>
>><br>
>> So you can do what you want later, but in all cases must give at<br>
>least one<br>
>> protocol struct to the context so you can get any callbacks.<br>
>><br>
>> -Andy<br>
>><br>
>> ><br>
>> >Thanks.<br>
>> >sthustfo<br>
>> ><br>
>> ><br>
>> ><br>
>> >On Tue, Aug 5, 2014 at 4:11 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br>
>> ><br>
>> >><br>
>> >><br>
>> >> On 5 August 2014 18:07:09 GMT+08:00, sthustfo <<a href="mailto:sthustfo@gmail.com">sthustfo@gmail.com</a>><br>
>> >wrote:<br>
>> >> >Hey Andy,<br>
>> >> ><br>
>> >> >Thanks for the quick response. I am not aware of the compliance<br>
>> >status<br>
>> >> >of<br>
>> >> ><a href="http://socket.io" target="_blank">socket.io</a> but am trying to find out the same. Meanwhile, here is<br>
>the<br>
>> >> >client<br>
>> >> >log with debug level 1023.<br>
>> >><br>
>> >> It seems to send us junk (|)<br>
>> >><br>
>> >> [411975:0442] CLIENT: nonblocking connect retry<br>
>> >> [411975:0442] CLIENT: libwebsocket_client_connect_2<br>
>> >> [411975:0442] CLIENT: libwebsocket_client_connect_2: address<br>
>> >127.0.0.1<br>
>> >> [411975:0442] CLIENT: connected<br>
>> >> [411975:0473] PARSER: WSI_TOKEN_NAME_PART '|'<br>
>> >> [411975:0473] INFO: Unknown method - dropping<br>
>> >> [411975:0474] WARN: problems parsing header<br>
>> >> [411975:0474] INFO: closing connection at<br>
>LWS_CONNMODE...SERVER_REPLY<br>
>> >><br>
>> >> If you didn't tell your server to support the protocols the test<br>
>> >clients<br>
>> >> uses, you wouldn't get any success anyway.  But it should just<br>
>close<br>
>> >the<br>
>> >> connection not send junk.<br>
>> >><br>
>> >> If you want to look further into it send the packet traces but I<br>
>> >guess it<br>
>> >> only supports some older RFC version of websockets.  Which is<br>
>> >probably a<br>
>> >> sign it's long unmaintained.<br>
>> >><br>
>> >> -Andy<br>
>> >><br>
>> >> >-<br>
>> >> >sthustfo<br>
>> >> ><br>
>> >> >On Tue, Aug 5, 2014 at 3:29 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
>wrote:<br>
>> >> ><br>
>> >> >><br>
>> >> >><br>
>> >> >> ><br>
>> >> >> >test@devpc:~/libwebsockets/build/bin$<br>
>./libwebsockets-test-client<br>
>> >> >> >127.0.0.1<br>
>> >> >> >--port=8888<br>
>> >> >><br>
>> >> >> Turn up the logging with -d 1023 or so<br>
>> >> >><br>
>> >> >> >libwebsockets test client<br>
>> >> >> >(C) Copyright 2010-2013 Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> licensed<br>
>> >under<br>
>> >> >> >LGPL2.1<br>
>> >> >> >[1457:9886] NOTICE: Initial logging level 7<br>
>> >> >> >[1457:9886] NOTICE: Library version: 1.3 67f9459<br>
>> >> >> >[1457:9887] NOTICE: IPV6 compiled in and enabled<br>
>> >> >> >[1457:9887] NOTICE: libev support not compiled in<br>
>> >> >> >[1457:9889] NOTICE:  static allocation: 4472 + (12 x 1024 fds)<br>
>=<br>
>> >> >16760<br>
>> >> >> >bytes<br>
>> >> >> >[1457:9890] NOTICE:  canonical_hostname = pk-laptop<br>
>> >> >> >[1457:9890] NOTICE:  per-conn mem: 128 + 1594 headers +<br>
>protocol<br>
>> >rx<br>
>> >> >buf<br>
>> >> >> >Waiting for connect...<br>
>> >> >> >[1457:9932] WARN: problems parsing header<br>
>> >> >> >Exiting<br>
>> >> >> >[1457:9933] NOTICE: libwebsocket_context_destroy<br>
>> >> >> ><br>
>> >> >> >And on the node server, I see the following log<br>
>> >> >> ><br>
>> >> >> >test@devpc:~/node$ DEBUG=* node basic.js<br>
>> >> >> >   info  - <a href="http://socket.io" target="_blank">socket.io</a> started<br>
>> >> >> >   debug - destroying <a href="http://non-socket.io" target="_blank">non-socket.io</a> upgrade<br>
>> >> >> >   debug - destroying <a href="http://non-socket.io" target="_blank">non-socket.io</a> upgrade<br>
>> >> >><br>
>> >> >> Is <a href="http://socket.io" target="_blank">socket.io</a> compliant with the actual websockets standard or<br>
>some<br>
>> >> >older<br>
>> >> >> RFC?<br>
>> >> >><br>
>> >> >> It seems it can't parse our upgrade request (which does pretty<br>
>> >good<br>
>> >> >at<br>
>> >> >> being compliant with everything else).<br>
>> >> >><br>
>> >> >> -Andy<br>
>> >> >><br>
>> >> >><br>
>> >><br>
>> >><br>
>><br>
>><br>
<br>
</div></div></blockquote></div><br></div></div>