The release of Firefox 3.5 included several new features for developers.
One of the most interesting new features is the support for cross-domain HTTP requests made with XMLHttpRequest objects (see here for details) or, by using Mozilla’s terminology, cross-origin requests.
It is well known that browsers enforce restrictions on the scripts that they execute, and one such restriction is the same-origin policy, which prevents a document or script loaded from one origin from getting or setting properties of a document from another origin.
Here “origin” means the scheme, host and port of the URL, so for example a script downloaded from http://foo.com could not make a request – via XMLHttpRequest – to http://bar.com (different host) or even http://foo.com:8080 (different port).
This same-origin restriction is so troublesome, that bright people figured out different ways of working around it.
It works, but way less reliably than the standard, same-origin, transport that it is used by default in Cometd applications.
Fortunately this troublesome restriction, which dates back to Netscape Navigator 2.0, has been addressed by a new W3C specification (the Cross-Origin Resource Sharing Specification), that however requires changes in how a client (such as the XMLHttpRequest object) and a server interact.
Firefox 3.5 already implements this specification (and I guess we can expect most if not all other browsers to do the same in short time), so the client part is taken care of.
For the server side, Jetty 7.0.0.RC2 now ships a servlet filter that implements the cross-origin specification allowing, for example, Cometd applications running on Firefox 3.5 to perform Bayeux communication with a server on a different origin using XMLHttpRequest instead of using the JSONP workaround.
You can find detailed information regarding Jetty’s cross-origin filter here, and regarding Cometd configuration for cross-origin Bayeux communication here.