JavaScript security model
When a JavaScript® client uses the XHR transport, this imposes security constraints on using cross domain requests.
The Diffusion™ JavaScript client library, unless otherwise configured, cascades downward through a set of transports starting with WebSocket and working its way down toward XmlHttpRequest (also known as Ajax Long Poll), and finally to hidden frames.
WebSocket, Flash®, and Silverlight® have few security constraints, however XHR is subject to the same origin policy. Simply put, if JavaScript code executes within a web page sourced from www.example.com it is only permitted to make XHR requests back to www.example.com. If your Diffusion server is at push.example.com this presents a problem when only XHR is available.
The catch-all solution
The set of web browsers in current use is both broad and heterogeneous. Rather than catering to each special case browser, this approach contains all complexity to one place: the load balancer. This presumes there is a load-balancer however, though in all reasonable production circumstances this is true. All XHR requests to Diffusion use a URL that starts /diffusion. Routing all such requests to one of the servers in the Diffusion pool will make available both regular and Diffusion functionality from one apparent host. This approach is suitable to all web browsers.

In circumstances where clients of Diffusion solutions cannot be depended upon to have a single IP address (for example: users with multiple aDSL connections, or smart-phones migrating between providers), each HTTP request made from a Diffusion client to a Diffusion server holds a cookie named session holding the unique session ID of that client. This gives load balancers an alternative means of distributing a request to one of their Diffusion servers.
Software alternatives
For test and development purposes a hardware load balancer might be an expensive means of compositing the URL-spaces of two (or more) web servers into one. Alternatives such a mod_proxy for the Apache™ web server, and an ISAPI_Rewrite tool can be employed to achieve the same for a lower (or zero) price-tag. Diffusion can be configured to run as a servlet with Tomcat. For more information, see Example: Deploying the Diffusion server within Tomcat.
cross-origin resource sharing (CORS)
CORS is a standard formed to address circumstances where www.example.com uses XHR to access resources on alternate host push.whatnot.com, and aims to provide sensible constraints and avoid a free-for-all.
CORS uses HTTP headers to enable the Diffusion server to indicate if it accepts traffic from web pages served from other servers. When a CORS request is made, Diffusion must respond with certain response HTTP headers for the browser to treat the request as successful. CORS requests can result in the browser sending a pre-flight request to Diffusion using the OPTIONS method to determine if the origin, headers, and methods of the request it is about to make are permitted. Diffusion responds with the correct values for headers and methods but the actual request is not made until the pre-flight request succeeds. The allowed origins can be configured in the client-service element of the WebServer.xml configuration file. For more information, see WebServer.xml.
Client-Side
Include the XHRURL attribute in the arguments to the DiffusionClientConnectionDetails constructor. For example:
var connectionDetails = { debug : true, onDataFunction : onDataEvent, XHRURL: "http://www.example.com:8080" topic : 'SYMBOLS/QUOTES/NIFTY~INDEX', }
Server side
CORS filtering is governed on the server side using the cors-origin attribute found in etc/WebServer.xml. By default this is a very permissive .* regular expression, and must be set to something more specific in production. In the above example, push.example.com will limit requests to push.example.com to only those from www.example.com. Full details about this feature are found in the web server section of the Diffusion manual.