sockjs / sockjs-client Goto Github PK

View Code? Open in Web Editor NEW

8.4K 8.4K 1.3K 4.17 MB

WebSocket emulation - Javascript client

License: MIT License

JavaScript 90.54% HTML 9.41% Shell 0.05%

javascript real-time sockjs websocket

sockjs-client's People

Contributors

Stargazers

Watchers

Forkers

razzededge gijs dmorlim-zz shripadk yihuang nehresma cgbystrom roadlabs nivertech julienmarie repos-websockets silversoft dineshkummarc msuess sunetos kjagiello mobilipia myusernamejeep aashley jordanliuhao jmars dturton diyjack tuffkid juliangruber chaosad raghunadhd rodmen satiri amitkumardas squaremo ryoh-miura thaingo maxhauser abpin st32lthx tdchien adiucu devinrhode2 ibank laychopy lholmquist vltr lddhbu jochenonline lujingfeng suryann j2ro berdichev mcollina leeaoran papandreou fudong1127 wyysf rollandx 3l3n01 shouby davidben shakakira plinskiy woerwin whtmlb mizafish microinfo chasel cmono ajunboys byphper faisal-w xiaonuogantan sunfc gangyu peanutpower roni5 sunsern isaiah gsingh-aimia chinnurtb kameshsampath dosht jongsix kangjia vikrantchoudhary laino newcomer520 linix-mod bwlee mnishihan crosma ronicthomas flaviogrossi fernandokahdal sorokins elidor86 bihicheng aixinnature sindtom xujack zldream1106 onsails

sockjs-client's Issues

Syntax error under IE7

I systematically get a syntax error at line 1 under IE7 if I try to connect with sockjs client. To reproduce the issue, just try to create a new SockJS object like this:

<html>
<body>
  <script src="http://cdn.sockjs.org/sockjs-0.1.js"></script>
  <script>new SockJS('http://example.com/');</script>
</body>
</html>

Describe CDN advantages

We should explain why using CDN is good. Example: http://encosia.com/3-reasons-why-you-should-let-google-host-jquery-for-you/

CDN 'sockjs-0.1.js' serves a 0.2 client.

Our application links to http://cdn.sockjs.org/sockjs-0.1.js, which we expected to always serve the latest 0.1-compatible client.

Before today, it served 0.1.2. But now, it serves 0.1.2.82.g295b. It appears this is code identical to 0.2, but with a different version number slapped on. This is breaking connection to our production 0.1 servers.

Any chance version 0.1.2.82.g295b can be revoked so that sockjs-0.1.js again serves 0.1.2?

Connection not closed on IE9 (using: iframe-htmlfile) when the browser is closed

Connect to the (code below) server on IE9
Either refresh the page (50% repo) or close the tab/browser (50% repo)

Observe no disconnect message by the server. Is this expected? A WebSocket connection (chrome) doesn't show the same behavior.

This is the server I was running to test (a quick modification of the echo.js server)

/*global require: false */
/*global __dirname: false */
/*global console: false */

var http = require('http');
var sockjs = require('sockjs');
var node_static = require('node-static');

// 1. Echo sockjs server
function do_nothing() {}

var sockjs_opts = {
    sockjs_url: "http://cdn.sockjs.org/sockjs-0.2.min.js",
    log: do_nothing
};

var sockjs_echo = sockjs.createServer(sockjs_opts);

var connections = {};
var nextConnectionId = 0;

function publishMessage(message)
{
    var c;
    for (c in connections)
    {
        if (connections.hasOwnProperty(c))
        {
            var connection = connections[c];
            connection.write(message);
        }
    }
}

function sockjs_connection(connection)
{
    connections[nextConnectionId] = connection;
    var connectionId = nextConnectionId;

    nextConnectionId += 1;

    var message = 'Connection from ' + connection.remoteAddress + ':' + connection.remotePort + ' with id ' + connectionId;
    console.log(message);
    publishMessage(message);

    function connection_data(message)
    {
        publishMessage(message);
    }

    function connection_close()
    {
        var message = 'Disconnect from ' + connection.remoteAddress + ':' + connection.remotePort + ' with id ' + connectionId;
        console.log(message);
        delete connections[connectionId];
        publishMessage(message);
    }

    connection.on('data', connection_data);
    connection.on('close', connection_close);
}

sockjs_echo.on('connection', sockjs_connection);

// 2. Static files server
var static_directory = new node_static.Server(__dirname);

// 3. Usual http stuff
var server = http.createServer();

function static_directory_listener(req, res)
{
    static_directory.serve(req, res);
}

function upgrade_listener(req, res)
{
    res.end();
}

server.addListener('request', static_directory_listener);
server.addListener('upgrade', upgrade_listener);

sockjs_echo.installHandlers(server, {prefix: '/echo'});

console.log(' [*] Listening on 0.0.0.0:9999');
server.listen(9999, '0.0.0.0');

Don't rely on Javascript PRNG

Javascript random numbers aren't cryptographically secure. Security research proved that in some cases they are easy to predict. We should consider using a custom PRNG:

http://baagoe.com/en/RandomMusings/javascript/

Or at least use the "entropy" from "info" request as a seed.

trying to access a ws:// web socket server

Hi Majek & Co.

We've been hunting for a silver bullet. We have been developing an HTML 5 (Sencha Touch) application for 8 months. Use Web Socket to move JSON data to/from a SQL Server DB to the SQLite DB on devices. We have developed a server side listener based around the Alchemy websocket system. Which has served us well during the development phase and works well with our 'app' on iPhone/Pad .. having been wrapped by Phonegap etc.

We have been keeping a watch on possible solutions for Androids and have looked at a few. Over the past 24 hours we've made an attempt to get SockJS to work. It seems to us that it won't connect to our web socket server ... which has a ws:// address. ... like ws://222.333.555.111:50555

Are we wasting our time here? Does your client only talk to http:// addressed servers?

Would be interested to hear from you

Regards
Roger

outdated tests

Please, update sockjs-client/tests server. It uses outdated SockJS.createServer() call
--Vladimir

Wrong reason in CloseEvent due to xhr.status=0 on xhr.abort()

Some browsers report no abort_reason and xhr.status === 0 on orderly abort(). This causes wrong reason in sockjs.onclose handler -- 'permanent' instead of 'user' -- and breaks further logic.

Firefox keeps websocket connection after leaving the page

Micheil Smith reported quite an interesting bug in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=696085

We should make sure sockjs/sockjs-client is not affected.

Try the test case to see if FF 8 is affected.
Verify if doing close onunload works.
Prepare a patch for sockjs!

Same Origin verification is wrong

This code is plain wrong, doesn't take port into account:

https://github.com/sockjs/sockjs-client/blob/0be70ef6323790c13f73d0bca25dc2b3407c2739/lib/utils.js#L26-31

xhr-streaming disconnect broken on IE?

A user suggests there is something wrong with xhr-streaming disconnect event on SockJS 0.1.2 and IE 8/9. Investigage.

Wrap upstream data message in array in websockets transport.

Currently, websocket transport don't wrap force message wrapped in array, but according to RFC 4627, only object and array are valid top level json, so i propose always wrap upstream data message in an array.

Safari on windows fails on "Running Dom: onunload" test

As in topic.

https://sockjs.popcnt.org/tests-qunit.html 
Running Dom: onunload

with

iframe error. bad.

REventTarget.prototype.addEventListener doesn't check for listener already added.

ESC in Firefox breaks sockjs connection

As found out by the Socket.io people:

http://groups.google.com/group/socket_io/browse_thread/thread/a705e4cb532e8808

XHR and JSONP mangle some unicode characters

Currently, due to limitations in browsers it is impossible to send some of the unicode characters over the wire. This affects mostly Chrome, Firefox behaves much better.

Don't leak iframe object in the dom.js - expose postMessage

In the dom.js we leak a reference to Iframe. This can cause the iframe not to be quickly gc'd and is generally bad. We should expose a dedicated postMessage function instead.

Remember last working transport

After we've done transport discovery, and the connection gets broken, we shouldn't do the discovery again.

Instead, if user wants to reconnect, we should just reuse previously detected transport.

Support the .pipe method as in nodejs Streams

So that you can stream from/to other sockets to the browser
http://nodejs.org/docs/v0.5.7/api/streams.html#stream.pipe

"[object Object]"

Why you add object to empty string in send function ?
Object every time converts to "[object Object]".

that._transport.doSend(utils.quote('' + data));

Your test does not cover this situation, because each time they compare string and string, but not objects.
You need to replace "equal" and "equals" test function to "same".

Loading spin of doom on jsonp

On FF and Chrome, not tested in IE.

http://cl.ly/3U2i1t1m1q1D0l3Z3N0n

Framing overhaul: Don't JSON-encode everything

Currently, which I do admit is a bit stupid, everything passed to SockJS is json-encoded. That should not be necessary, especially for protocols that can do binaries - websockets.

This will require a major change in the protocol.

It's also not going to be simple due to the fact that we may need some encoding for the iframe communication.

Emit 'heartbeat' event.

This is not defined by the spec, but it appears that exposing underlying 'heartbeat' events could be useful.

IE9 in debug mode

Hi!

https://github.com/sockjs/sockjs-client/blob/master/tests/html/src/tests.coffee#L411

For truly IE<8 browsers it works ok. For IE9 in IE<9 modes it causes test failure. We need more robust checking here, imho, and a warning in README on how to test older IE.

Best regards,
--Vladimir

`send` shouldn't allow complex data types

Only strings, as per websockets spec.
(we don't do Blobs and typed arrays for now)

It should behave in a similar way to what chrome does - converting a value to a string. For example if you try sending a number 1 a string 1 will be send.

Does "protocols" not work at all?

var sockjs = new SockJS(url, protocols, options); <-- it looks like you can pass ['websockets'] to protocols, but that doesn't seem to be working.

In Sockjs 0.2 safari less likely to use native websockets

It looks that since 0.2 Safari is less likely to use websockets and more often falls back to xhr-polling.

This may be caused by general slowness of safari, or safari websockets implementation.

For example, connecting to host in the same network takes about 14ms in safari and 4ms in chrome.

Raise an exception on empty base_url

The websockets spec says:

Parse a WebSocket URL's components from the url argument, to obtain host, port, resource name, and secure. If this fails, throw a SYNTAX_ERR exception and abort these steps. [WSP]

`status` property on CloseEvent should be called `code`

I got that wrong. See sockjs-node bug. Spec clearly says:

Create an event that uses the CloseEvent interface, with the event name close, [...] whose wasClean attribute is initialized to true if the connection closed cleanly and false otherwise, whose code attribute is initialized to the WebSocket connection close code, and whose reason attribute is initialized to the WebSocket connection close reason decoded as UTF-8

AMD Compliance

Any chance this can be added? Should be as simple as

if typeof define is 'function'
   define SockJS
else
   window.SockJS = SockJS

Inline license

The license should be included verbatim at the top of the released file.

Get rid of chunking_test

Protocol changes: sockjs/sockjs-protocol#7

XHR requests linger on behind haproxy

@shripadk on IRC reports

 [22:55] <shripadk> while behind a proxy (ex: haproxy)
 [22:55] <shripadk> i notice that if the backend server crashes
 [22:55] <shripadk> xhr requests linger on
 [22:55] <shripadk> looks like there is no timeout set client side
 [22:56] <shripadk> doesn't that cause unnecessary load on the server?

iframe-htmlfile not stable in ie8

During the work on #52 we realized that iframe-htmlfile is not as stable as it should be. It seems to work okay in generic case, but it often fails to establish connection again after hitting F5/refresh.

To reproduce:

clone https://gist.github.com/2038177
open browser
hit f5
fail to see a new 'connection' line in node console output

Get IE10 working

Htmlfile transport

In order to support JSESSIONID load balancing we need a streaming transport for IE that supports cookies. XDR is great, but it doesn't send cookies. Thus a need for something else - htmlfile for example.

Options for fallbacks?

For example, to set the polling frequency.

robuster browser detection is needed

IE9 in standard document mode pretends to be a good browser. In particular, checking whether browser is IE with typeof _document.attachEvent === 'object' gives false negatives. This lead to subtle errors. To name one, jsonp-polling transport stops functioning correctly.

Proposed fix to jsonp-polling for IE is at #21

I believe we should determine browser once (then cache it in SockJS object) and more carefully

SockJS doesn't work when served from file://

As mentioned here: d67c678

It's worth noting that Phonegap serves files from file:// urls.

Print fat warning on more than one sockjs connection

We should test if sockjs can open multiple connections given multiple subdomains. We should also print a big fat warning if user tries to open more than one conneciton to a single domain.

Can't establish SockJS connection before body loads

Hi!

https://github.com/sockjs/sockjs-client/blob/master/lib/utils.js#L242 -- _document.body === null. Changing to _document.appendChild fixes for IE7-8 (have no IE6 with my grasp). Still, IE9 throws SCRIPT5022: DOM Exception: HIERARCHY_REQUEST_ERR (3) in its Standard document mode.

--Vladimir

Xhr-polling is uses /xhr url

This is inconsistent. xhr-polling should use /xhr-polling url.

What happens if sockJS gets disconnected?

Will it automatically reconnect or should I code some custom reconnect into on('close')?

Flowchart for transports

Document transports - in a visual way.

Investigate silverlight websocket client

I recently found this:

It would be interesting to see if/how it works.

Update links in wiki

The links in the main wiki page are still pointing to the old repo
https://github.com/sockjs/sockjs-client/wiki

Probably, better to make them relative

SockJS-client reuses session_id for fallbacks

Each try to connect to sockjs server should have a new, unique session. Session id should never be reused.

Reference: sockjs/sockjs-protocol#25

sockjs disable back button for opera

I hit the back button once, nothing happens, hit it again I am taken back to where I came from. Sometimes required more hits.

in cleanup function there's hack for ie: iframe.src = "about:blank";
it's lead to the interception of back button for opera.

Solution (in utils.createIframe cleanup):

iframe.src = "about:blank";
if(!-[1,]) iframe.src = "about:blank"; // (!-[1,]) for detect ie, could be something else

Busy indicator fix for jsonp on FF

Support streaming transport on IE7, if we're not using cross-domain.

Currently IE7 falls back to polling transports - as there is no way of doing cross-domain streaming protocol. But for deployments that are not cross-domain, we might support streaming, for example htmlfile, why not.