If you only need to send data to the server, this is easily done by submitting a form (with form.submit()). To prevent the browser from leaving the current page and loading the server's response, either have the server respond with 204 No Content (in AOLserver this is as easy as [ns_return 204 "" ""]) or set the form's target to a hidden IFRAME.
But what if you need to get the server's response? Although you can load the server's response into a hidden IFRAME, for security reasons, the parent window is unable to read anything from the document in the IFRAME, nor can the code in the IFRAME set anything in the parent window (or read from it).
There is just one exception - although a window cannot READ window.location of another window in a different domain, it can SET it. Normally, this isn't very helpful because setting location causes the browser to load that URL. However, if you only change the part of the URL after # (i.e. the anchor) to a non-existent anchor, the browser will do nothing (except possibly make a clicking sound).
While the parent window can set the hash in a child frame/window directly, the child frame/window cannot set just the hash property of the parent. It can only set the entire URL. This is not trivial because we cannot READ the parent window's URL.
In IE7, we cannot set the URL of the parent window if that window is itself an IFRAME in some parent window.
The hash string has a limited length, 4000 characters in IE.
Here, I present a pretty simple way of setting up a page that can get a short message with just a little bit of help from the server. Note that neither solution will allow you to consume arbitrary web services on the Internet - there is just no way to do that without a server-side proxy of some kind.
To work around issue number 2 above, we can create our hidden IFRAME in the top-most window, which is presumably in the same domain as the window/frame that needs to perform the communication. Since this is fairly straightforward, for clarity, I am just going to omit dealing with this issue :-).
The nice thing about this approach is we can use the exact same response for requests that are wired to read this message through this method, as well as regular requests such as form submissions that just expect a normal pretty human-readable response. This works because a window will either have no parent or the window's URL will match the Referer and setting its URL to itself will have no ill effects. Although this example uses Tcl/AOLserver/our own APIs, it's pretty self-explanatory:
After that, the normal human-readable response body follows. Since this is such a simple and low-impact change on the server, you can have all your responses that you can foresee being used by pages in another domain include this. To make this easy in AOLserver, our modified version of ns_returnnotice now has an optional parameter for the string to use as $message above.
The following client-side code is needed in the parent window to actually read such as response and place it into a span with id of "response":
As you can see, it's not really that complicated. It gets more complicated if the server needs to respond with more than 4000 characters worth of information. To be able to do this, the child window would need to first tell the parent window its URL, then break the response into 4000-character chunks and set them one at a time waiting for an acknowledgement that the chunk has been processed, which the parent window would set in the child's hash.
One last thing. Frequently, it's
convenient to be able to create a hidden IFRAME on the fly,
especially if you need to create it in the top-most window
to work around the IE7 problem. You can use our
createHiddenIFrame function which is based on the code in