Home ›

At the Forge - Communication in HTML5

Issue 202

From Issue #202
February 2011

Mar 31, 2011  By Reuven M. Lerner
 in
HTML5 gives Web applications new communication features.

Listing 1. atf.html, the Container HTML Page


<!DOCTYPE html>
<head>
<title>Page title</title>
<script src="jquery.js"></script>

<script>
   $(document).ready(function() {
   window.addEventListener('message', receiver, false);
   function receiver(e) {
       alert("origin = '" + e.origin + "'");
       alert("data = '" + e.data + "'");
           $("#message").val(e.data);
   };
   });
</script>

</head>
<body>
<h1>Page headline</h1>
<p id="message">[No message yet]</p>

<iframe id="my-iframe" src="iframe.html" />
</body>
</html>

Inside this page is an iframe. Now, for demonstration purposes, this iframe will have the same origin as the outer page. But in many cases, the iframe will come from a completely different origin. In HTML5, that doesn't matter at all. You can send a message to whichever recipient you like. If you look at the HTML source for iframe.html, you'll see how to accomplish this: 

$(document).ready(function() {
$("#send-button").click(function() {
    window.parent.postMessage($("#text-to-send").val(), '*');
});
});

In this example, I use jQuery to grab the button whose ID is “send-button”. I then add an event handler to that button, indicating that when it is clicked, it should invoke window.parent.postMessage, sending the text contained inside the text field. I should note that the postMessage() method can be called on any window or iframe, and that it can send any text in its first parameter.

Listing 2. iframe.html, the Contents of Which Are Loaded into an iframe


<!DOCTYPE html>
<head>
<title>iframe title</title>
<script src="jquery.js" /></script>
</head>
<body>
<h1>iframe headline</h1>

<p>Text to send: <input type="text" id="text-to-send" /></p>
<p><input id="send-button" type="button" value="Send it!" /></p>

<script>
$(document).ready(function() {
   $("#send-button").click(function() {
       window.parent.postMessage($("#text-to-send").val(), '*');
   });
});
</script>


</body>
</html>

The second parameter indicates the origin of the recipient to whom you're sending this message. In this case, I have indicated that the recipient may have any origin by specifying a wild card. In production environments, it's probably safe to assume you will want to specify an origin. By stating the recipient's origin, there's a bit of additional safety—the message will be sent only if the receiving window object's content is from the stated origin.

On the receiver's end, the posted message arrives as an event, one which the receiver can (and should!) examine before using. Going back to atf.html, you will see how the receiver accepts a message in its event handler: 

$(document).ready(function() {
window.addEventListener('message', receiver, false);
function receiver(e) {
    alert("origin = '" + e.origin + "'");
    alert("data = '" + e.data + "'");
        $("#message").text(e.data);
};
});

The event handler for this page indicates that it's willing to accept a message. Each message consists of two pieces, the message (the text string that the sender passed as a parameter to postMessage) and the origin (the sender's origin). Note that the sender cannot set its origin; this piece of information is handled by the browser.

Because the origin information is passed along with the message, it's possible for the receiver to filter out which origins it is willing to accept. In other words, although it's possible a rogue site will try to start posting to random windows that you might have open on other sites, the only way such messages actually will arrive is if the receivers are willing to accept them. I'm sure someone with more of a black-hat mentality than mine will find ways to defeat this security mechanism, but from what I can tell, it was thought out very carefully and cleverly, and should avoid most mischief.

Now that it's possible for any window to send messages to any other window, what can you do with it? The answer, of course, is that no one knows. Off of the top of my head, I can imagine chat clients—or more generally, using a single window on a Web browser as a communication switchboard and clearinghouse—grabbing feeds and incoming messages and putting them on the appropriate pages. Imagine if Facebook were to have a single iframe that would handle its (very large!) number of interactions with the server, and then handle all page updates through that iframe, rather than on each individual window or tab.

I also can imagine the postMessage() method ushering in a new age of multiwindow, desktop-like applications. Think of how many desktop applications now use multiple windows—one for control, another for each document and yet another for a “palette” of options. Now you can do the same thing with a Web browser, with a native message-passing interface.

Just what people will do with these capabilities is unknown, but I predict we'll see a rash of new, rich, browser-based applications that take advantage of them.

______________________

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions