The CometD project implements various Comet techniques to implement a web messaging bus.
You can find an introduction to CometD here.
Web applications often need to access resources residing on different servers, making the request to access those resources a cross origin request and therefore subject to the same origin policy.
Fortunately, all modern browsers implement the Cross Origin Resource Sharing (CORS) specification, and with the support of Jetty‘s Cross Origin Filter, it’s a breeze to write applications that allow cross origin resource sharing.
That is, all modern browsers apart Internet Explorer 8 and 9.
Without CORS support, CometD fallbacks to another Comet technique known as JSONP.
While JSONP is much less efficient than a CORS request, it guarantees the CometD functionality, but it’s 2011 and JSONP should be a relic of the past.
Microsoft’s browsers have another JavaScript object that allows to make cross origin request: XDomainRequest.
Unfortunately this object is non-standard, and it is not, in general, supported by the JavaScript toolkits on which CometD relies for the actual communication with the server.
I cannot really blame toolkits authors for this lack of support.
However, I recently found a way to make XDomain request work with CometD 2.4.0 and the Dojo toolkit library.
The solution (see this blog post for reference) is the following:
Add this code to your JavaScript application:

dojo.require("dojox.io.xhrPlugins");
...
dojox.io.xhrPlugins.addCrossSiteXhr("http://<crossOriginHost>:<crossOriginPort>");

What remains is to configure CometD with the crossOriginHost:

dojox.cometd.configure({
    url: "http://<crossOriginHost>:<crossOriginPort>"
});

The last glitch is that XDomainRequest does not seem to allow to send the Content-Type HTTP header, so all of the above will only work in CometD 2.4.0.RC1 or greater where this improvement has been made.
I do not particularly recommend this hack, but sometimes it’s the only way to support cross origin requests for the obsolete Internet Explorers.


5 Comments

Mathieu · 07/11/2011 at 16:07

We are using CometD with jQuery & jQuery Mobile to server a multiple sub-domain website (jaxspot.com) with CORS. The website is working well event with IE8 & 9. We developed a jQuery plugin which automatically uses the XDomain object if necessary in IE.
See http://blog.mycila.com/2011/07/jquery-cors-plugin.html
For explanations and source code.

Ari King · 01/12/2011 at 01:31

Have you been able to get CORS to work with Jetty/Jetty-Maven Plugin? If yes, how? I’ve configured my web application, via jetty-maven plugin, to use Jetty’s cross origin filter. When I execute mvn jetty:run, the app runs, but it does NOT send the correct “Access-Control-Allow-Origin: *” header in responses. Any ideas on what could be wrong and how to fix it? Thanks.

CometD, Dojo and XDomainRequest | Eclipse | Syngu · 08/11/2011 at 06:39

[…] The CometD project implements various Comet techniques to implement a web messaging bus. You can find an introduction to CometD here.Web applications often need to access resources residing on different servers, making the request to access those resources a cross origin request and therefore subject to the same origin policy.Fortunately, all modern browsers implement the Cross Origin Resource Sharing (CORS) specification, and with the support of Jetty‘s Cross Origin Filter, it’s a breeze to write applications that allow cross origin resource sharing.That is, all modern browsers apart Internet Explorer 8 and 9.Without CORS support, CometD fallbacks to another Comet technique known as JSONP. While JSONP is much less efficient than a CORS request, it guarantees the CometD functionality, but it’s 2011 and JSONP should be a relic of the past.Microsoft’s browsers have another JavaScript object that allows to make cross origin request: XDomainRequest.Unfortunately this object is non-standard, and it is not, in general, supported by the JavaScript toolkits on which CometD relies for the actual communication with the server. I cannot really blame toolkits authors for this lack of support.However, I recently found a way to make XDomain request work with CometD 2.4.0 and the Dojo toolkit library.The solution (see this blog post for reference) is the following:Add this code to your JavaScript application:dojo.require("dojox.io.xhrPlugins"); … dojox.io.xhrPlugins.addCrossSiteXhr("http://<crossOriginHost&gt;:<crossOriginPort>"); What remains is to configure CometD with the crossOriginHost:dojox.cometd.configure({ url: "http://<crossOriginHost&gt;:<crossOriginPort>" }); The last glitch is that XDomainRequest does not seem to allow to send the Content-Type HTTP header, so all of the above will only work in CometD 2.4.0.RC1 or greater where this improvement has been made.I do not particularly recommend this hack, but sometimes it’s the only way to support cross origin requests for the obsolete Internet Explorers.    Eclipse Read the original post on Planet Eclipse… […]

Distributed Weekly 128 — Scott Banwart's Blog · 11/11/2011 at 13:48

[…] CometD, Dojo and XDomainRequest […]

CometD, Dojo and XDomainRequest | Webtide Blogs | EtondeGroup Blog of Web Applications · 17/11/2011 at 23:55

[…] the original post: CometD, Dojo and XDomainRequest | Webtide Blogs Bookmark on Delicious Digg this post Recommend on Facebook share via Reddit Share with Stumblers […]

Comments are closed.