xhr-* transports do not handle cross-domain requests

[mscdex]

I noticed that the xhr-* transports do not support cross-domain requests, while the websocket transport does (by checking the listener's origin property).

I didn't realize what the exact problem was until I did a fair amount of digging. It looks like xhr-* transports may have to listen for the 'OPTIONS' HTTP method and respond appropriately for this to work? Apparently the 'OPTIONS' method is a "pre-flight" message that is essentially requesting to make a request to the server and a message has to be sent back for the real (GET in Socket.io's case) request to occur.

I'll try and see if I can get something going, but I wasn't sure if support for this is coming soon or not?

[TooTallNate]

XmlHttpRequest is indeed restricted by the Same Origin Policy. Google it if you haven't read up on it. I don't know of this 'OPTIONS' HTTP method for making cross-domain xhr calls, however I do know of a special HTTP header that can be sent by the server:

Access-Control-Allow-Origin: *

See here for more info. Note that the special HTTP header is not supported by all browsers.

[rauchg]

It's one of our issues in GitHub already. Basically the different transports classes have to expose a crossdomain property so that we perform feature detection AND check if we're dealing with cross domains, and choose a transport appropriately.

[mscdex]

Ok, well I've mostly only had to make changes on the server-end (to send the access-control headers when an origin header is found, etc), with a few tweaks needed on the client-end (to fix some bugs I noticed also). After these changes, everything is working well :-)

[TooTallNate]

Cool, you should make a patch/fork and pull request!

[mscdex]

Here are the patches for the changes I made.

To do cross-domain XHR you need Firefox v3.5+, Safari v4+, Google Chrome v2+, or IE8.

IE8's proprietary XDomainRequest class still needs to be included/implemented on the client-side xhr-* transports though and XDomainRequest so far does not support sending credentials (cookies and/or http auth) with the request (aka "withCredentials").

Lastly, I found that when doing multipart streaming, the XHR has no way of knowing when the connection to the server is closed. To overcome this problem, I implemented a simple ping timeout to determine if the server dies or otherwise loses connection with the client.

[mscdex]

Just a quick update -- there is an error in the patch above. The xhr-polling's call to this._request in its connect function should NOT have a third parameter specified.

Also, I am in the process of incorporating XDR support for IE8 with checks for cross-domain and all that jazz. XDR is pretty limiting, so it looks like we may need to find a better (new) transport for IE users? jsonp? script tag?

[rauchg]

mscdex, for IE we should have JSONP long-polling.

[mscdex]

There is also XDR for IE8+. I haven't worked on it in awhile, but I just need to put the finishing touches on the XHR cross-domain support for socket.io-node and socket.io that I incorporated.

[mscdex]

I'm starting to work more on this again. I think for IE (<8) or any other browser that doesn't support any "next generation" method of cross-domain requests, jsonp is probably the best fallback before failure.

However, not all browsers support (or use the same API for) error checking methods and other mechanisms that make script request long polling feasible. The jquery-jsonp plugin (http://code.google.com/p/jquery-jsonp/) may be worth looking at as a model for handling some of these compatibility issues when using jsonp.

[johnboxall]

You might want to checkout my fork that adds support for cross domain connections using JSONP:

http://github.com/johnboxall/Socket.IO-node/blob/master/lib/socket.io/transports/script.js

http://github.com/johnboxall/Socket.IO/blob/master/lib/transports/script.js

[mscdex]

@johnboxall: looks like a good start. One thing I would suggest is to look into dynamically creating jsonp callbacks (using a randomly generated name) to distinguish jsonp requests from one instance of a socket.io client from another. Then the callback can be removed from the global namespace after either a timeout occurs or the callback is executed.

[tobsn]

is there a correct fallback for IE6 and browser who doesnt support any given transport protocols?

[mscdex]

@tobsn: probably htmlfile or jsonp.

[tobsn]

my IE6 in parallels had no flash installed - worked after i installed flash and started using websockets... is there any way to test this? IE version is: 6.0.2900.3300.xpsp.080125-2028 (XP with SP3)

[tobsn]

it pretty much works but its not getting any connection together without flash installed...