HotDog Stand Owner: OK Buddy, here ya go. That'll be $20.00.
Zen Master: Here twenty dollar bill.
HotDog Stand Owner: That'll do it, pal. Have a great day!
Zen Master: What about change?
HotDog Stand Owner: Ah, change... must come from within!
This is an area where I (and many others) have been quite vocal in complaining. If you can point the src property of a <script... tag at another domain, and said script can basically do anything it wants, then why can't you make an XmlHttpRequest to another domain (other than the one from which the page emanated)?
It's certainly an inconsistent application of the notion of security, at a minimum.
So in Internet Explorer 8.0 you have the new IHTMLXDomainRequest Interface.
Here's how it works, in a nutshell:
Cross-domain requests ("XDR", for short) require mutual consent between the webpage and the server. You can initiate a cross-domain request in your webpage by creating an XDomainRequest object off the window object, and then opening a connection to a particular domain. The browser will request data from the domain's server by sending an "XDomainRequest: 1" header. It will only complete the connection if the server responds with an "XDomainRequestAllowed" header with the value "1" (for true).
For example, a page might have this code, which would allow XDomain requests:
Here is a short client script sample of how a request would be made:
// 1. Create XDR object
xdr = new XDomainRequest();
// 2. Open connection with server using POST method
// 3. Send string data to server
The result comes back in the responseText property, and there are some simple events:
And, aside from the requirement for the headers as described above, that's pretty much the whole deal.
You can look at the standard MSDN style documentation for all this here.