HTML5 Web Messaging

W3C Working Draft 18 November 2010

This Version:: http://www.w3.org/TR/2010/WD-webmessaging-20101118/
Latest Published Version:: http://www.w3.org/TR/webmessaging/
Latest Editor's Draft:: http://dev.w3.org/html5/postmsg/
Editors:: Ian Hickson, Google, Inc.

The bulk of the text of this specification is also available in the WHATWG Web Applications 1.0 specification, under a license that permits reuse of the specification text.

Abstract

This specification defines two mechanism for communicating between browsing contexts in HTML documents.

Status of This document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

If you wish to make comments regarding this document in a manner that is tracked by the W3C, please submit them via using our public bug database.

If you cannot do this then you can also e-mail feedback to public-html-comments@w3.org (subscribe, archives), and arrangements will be made to transpose the comments to our public bug database. Alternatively, you can e-mail feedback to whatwg@whatwg.org (subscribe, archives). The editor guarantees that all substantive feedback sent to this list will receive a reply. However, such feedback is not considered formal feedback for the W3C process. All feedback is welcome.

The working groups maintain a list of all bug reports that the editor has not yet tried to address and a list of issues for which the chairs have not yet declared a decision. The editor also maintains a list of all e-mails that he has not yet tried to address. These bugs, issues, and e-mails apply to multiple HTML-related specifications, not just this one.

The publication of this document by the W3C as a W3C Working Draft does not imply that all of the participants in the W3C Web Applications working group endorse the contents of the specification. Indeed, for any section of the specification, one can usually find many members of the working group or of the W3C as a whole who object strongly to the current text, the existence of the section at all, or the idea that the working group should even spend time discussing the concept of that section.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The latest stable version of the editor's draft of this specification is always available on the W3C CVS server and in the WHATWG Subversion repository. The latest editor's working copy (which may contain unfinished text in the process of being prepared) contains the latest draft text of this specification (amongst others). For more details, please see the WHATWG FAQ.

There are various ways to follow the change history for the HTML specifications:

E-mail notifications of changes: HTML-Diffs mailing list (diff-marked HTML versions for each change): http://lists.w3.org/Archives/Public/public-html-diffs/latest; Commit-Watchers mailing list (complete source diffs): http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org
Real-time notifications of changes:: Generated diff-marked HTML versions for each change: http://twitter.com/HTML5; All (non-editorial) changes to the spec source: http://twitter.com/WHATWG
Browsable version-control record of all changes:: CVSWeb interface with side-by-side diffs: http://dev.w3.org/cvsweb/html5/; Annotated summary with unified diffs: http://html5.org/tools/web-apps-tracker; Raw Subversion interface: svn checkout http://svn.whatwg.org/webapps/

The W3C Web Applications Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track. This specification is the 18 November 2010 First Public Working Draft.

Work on this specification is also done at the WHATWG.

This specification is an extension to the HTML5 language. All normative content in the HTML5 specification, unless specifically overridden by this specification, is intended to be the basis for this specification.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

1 Conformance requirements
2 Event definitions
3 Cross-document messaging
4 Channel messaging
References
Acknowledgements

1 Conformance requirements

This specification is an HTML specification. All the conformance requirements, conformance classes, definitions, dependencies, terminology, and typographical conventions described in the core HTML5 specification apply to this specification. [HTML5]

Interfaces are defined in terms of Web IDL. [WEBIDL]

2 Event definitions

Messages in server-sent events, Web sockets, cross-document messaging, and channel messaging use the message event. [EVENTSOURCE] [WEBSOCKET]

The following interface is defined for this event:

interface MessageEvent : Event {
  readonly attribute any data;
  readonly attribute DOMString origin;
  readonly attribute DOMString lastEventId;
  readonly attribute WindowProxy source;
  readonly attribute MessagePortArray ports;
  void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any dataArg, in DOMString originArg, in DOMString lastEventIdArg, in WindowProxy sourceArg, in MessagePortArray portsArg);
};

event . data: Returns the data of the message.
event . origin: Returns the origin of the message, for server-sent events and cross-document messaging.
event . lastEventId: Returns the last event ID, for server-sent events.
event . source: Returns the WindowProxy of the source window, for cross-document messaging.
event . ports: Returns the MessagePortArray sent with the message, for cross-document messaging and channel messaging.

The initMessageEvent() method must initialize the event in a manner analogous to the similarly-named method in the DOM Events interfaces. [DOMEVENTS]

The data attribute represents the message being sent.

The origin attribute represents, in server-sent events and cross-document messaging, the origin of the document that sent the message (typically the scheme, hostname, and port of the document, but not its path or fragment identifier).

The lastEventId attribute represents, in server-sent events, the last event ID string of the event source.

The source attribute represents, in cross-document messaging, the WindowProxy of the browsing context of the Window object from which the message came.

The ports attribute represents, in cross-document messaging and channel messaging the MessagePortArray being sent, if any.

Except where otherwise specified, when the user agent creates and dispatches a message event in the algorithms described in the following sections, the lastEventId attribute must be the empty string, the origin attribute must be the empty string, the source attribute must be null, and the ports attribute must be null.

3 Cross-document messaging

Web browsers, for security and privacy reasons, prevent documents in different domains from affecting each other; that is, cross-site scripting is disallowed.

While this is an important security feature, it prevents pages from different domains from communicating even when those pages are not hostile. This section introduces a messaging system that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks.

The task source for the tasks in cross-document messaging is the posted message task source.

3.1 Introduction

This section is non-normative.

For example, if document A contains an iframe element that contains document B, and script in document A calls postMessage() on the Window object of document B, then a message event will be fired on that object, marked as originating from the Window of document A. The script in document A might look like:

var o = document.getElementsByTagName('iframe')[0];
o.contentWindow.postMessage('Hello world', 'http://b.example.org/');

To register an event handler for incoming events, the script would use addEventListener() (or similar mechanisms). For example, the script in document B might look like:

window.addEventListener('message', receiver, false);
function receiver(e) {
  if (e.origin == 'http://example.com') {
    if (e.data == 'Hello world') {
      e.source.postMessage('Hello', e.origin);
    } else {
      alert(e.data);
    }
  }
}

This script first checks the domain is the expected domain, and then looks at the message, which it either displays to the user, or responds to by sending a message back to the document which sent the message in the first place.

3.2 Security

3.2.1 Authors

Use of this API requires extra care to protect users from hostile entities abusing a site for their own purposes.

Authors should check the origin attribute to ensure that messages are only accepted from domains that they expect to receive messages from. Otherwise, bugs in the author's message handling code could be exploited by hostile sites.

Furthermore, even after checking the origin attribute, authors should also check that the data in question is of the expected format. Otherwise, if the source of the event has been attacked using a cross-site scripting flaw, further unchecked processing of information sent using the postMessage() method could result in the attack being propagated into the receiver.

Authors should not use the wildcard keyword (*) in the targetOrigin argument in messages that contain any confidential information, as otherwise there is no way to guarantee that the message is only delivered to the recipient to which it was intended.

3.2.2 User agents

The integrity of this API is based on the inability for scripts of one origin to post arbitrary events (using dispatchEvent() or otherwise) to objects in other origins (those that are not the same).

Implementors are urged to take extra care in the implementation of this feature. It allows authors to transmit information from one domain to another domain, which is normally disallowed for security reasons. It also requires that UAs be careful to allow access to certain properties but not others.

3.3 Posting messages

window . postMessage(message, targetOrigin [, ports ])

Posts a message, optionally with an array of ports, to the given window.

If the origin of the target window doesn't match the given origin, the message is discarded, to avoid information leakage. To send the message to the target regardless of origin, set the target origin to "*". To restrict the message to same-origin targets only, without needing to explicitly state the origin, pass the window.location object.

Throws an INVALID_STATE_ERR if the ports array is not null and it contains either null entries or duplicate ports.

When posting a message to a Window of a browsing context that has just been navigated to a new Document is likely to result in the message not receiving its intended recipient: the scripts in the target browsing context have to have had time to set up listeners for the messages. Thus, for instance, in situations where a message is to be sent to the Window of newly created child iframe, authors are advised to have the child Document post a message to their parent announcing their readiness to receive messages, and for the parent to wait for this message before beginning posting messages.

When a script invokes the postMessage(message, targetOrigin, ports) method (with two or three arguments) on a Window object, the user agent must follow these steps:

If the value of the targetOrigin argument is neither a single U+002A ASTERISK character (*) nor an absolute URL, then throw a SYNTAX_ERR exception and abort the overall set of steps.
Let message clone be the result of obtaining a structured clone of the message argument. If this throws an exception, then throw that exception and abort these steps.
If the ports argument is present but either any of the entries in ports are null, or any MessagePort object is listed in ports more than once, or any of the MessagePort objects listed in ports have already been cloned once before, then throw an INVALID_STATE_ERR exception and abort these steps.
Let new ports be an empty array.

If the ports argument is present, then for each port in ports in turn, obtain a new port by cloning the port with the Window object on which the method was invoked as the owner of the clone, and append the clone to the new ports array.

If the original ports argument was omitted or empty, then the new ports array will be empty.
Return from the postMessage() method, but asynchronously continue running these steps.
Otherwise, if the targetOrigin argument is an absolute URL, and the Document of the Window object on which the method was invoked does not have the same origin as targetOrigin, then abort these steps silently.

Otherwise, the targetOrigin argument is a single literal U+002A ASTERISK character (*), and no origin check is made.
Create an event that uses the MessageEvent interface, with the event name message, which does not bubble, is not cancelable, and has no default action. The data attribute must be set to the value of message clone, the origin attribute must be set to the Unicode serialization of the origin of the script that invoked the method, the source attribute must be set to the script's global object's WindowProxy object, and the ports attribute must be set to the new ports array.
Queue a task to dispatch the event created in the previous step at the Window object on which the method was invoked. The task source for this task is the posted message task source.

4 Channel messaging

4.1 Introduction

This section is non-normative.

To enable independent pieces of code (e.g. running in different browsing contexts) to communicate directly, authors can use channel messaging.

Communication channels in this mechanisms are implemented as two-ways pipes, with a port at each end. Messages sent in one port are delivered at the other port, and vice-versa. Messages are asynchronous, and delivered as DOM events.

To create a connection (two "entangled" ports), the MessageChannel() constructor is called:

var channel = new MessageChannel();

One of the ports is kept as the local port, and the other port is sent to the remote code, e.g. using postMessage():

otherWindow.postMessage('hello', 'http://example.com', [channel.port2]);

To send messages, the postMessage() method on the port is used:

channel.port1.postMessage('hello');

To receive messages, one listens to message events:

channel.port1.onmessage = handleMessage;
function handleMessage(event) {
  // message is in event.data
  // ...
}

4.2 Message channels

[Constructor]
interface MessageChannel {
  readonly attribute MessagePort port1;
  readonly attribute MessagePort port2;
};

channel = new MessageChannel(): Returns a new MessageChannel object with two new MessagePort objects.
channel . port1: Returns the first MessagePort object.
channel . port2: Returns the second MessagePort object.

When the MessageChannel() constructor is called, it must run the following algorithm:

Create a new MessagePort object owned by the script's global object, and let port1 be that object.
Create a new MessagePort object owned by the script's global object, and let port2 be that object.
Entangle the port1 and port2 objects.
Instantiate a new MessageChannel object, and let channel be that object.
Let the port1 attribute of the channel object be port1.
Let the port2 attribute of the channel object be port2.
Return channel.

This constructor must be visible when the script's global object is either a Window object or an object implementing the WorkerUtils interface.

The port1 and port2 attributes must return the values they were assigned when the MessageChannel object was created.

4.3 Message ports

Each channel has two message ports. Data sent through one port is received by the other port, and vice versa.

typedef sequence<MessagePort> MessagePortArray;

interface MessagePort {
  void postMessage(in any message, in optional MessagePortArray ports);
  void start();
  void close();

  // event handlers
           attribute Function onmessage;
};
MessagePort implements EventTarget;

port . postMessage(message [, ports] )

Posts a message through the channel, optionally with the given ports.

Throws an INVALID_STATE_ERR if the ports array is not null and it contains either null entries, duplicate ports, or the source or target port.

port . start()

Begins dispatching messages received on the port.

port . close()

Disconnects the port, so that it is no longer active.

Each MessagePort object can be entangled with another (a symmetric relationship). Each MessagePort object also has a task source called the port message queue, initial empty. A port message queue can be enabled or disabled, and is initially disabled. Once enabled, a port can never be disabled again (though messages in the queue can get moved to another queue or removed altogether, which has much the same effect).

When the user agent is to create a new MessagePort object owned by a script's global object object owner, it must instantiate a new MessagePort object, and let its owner be owner.

When the user agent is to entangle two MessagePort objects, it must run the following steps:

If one of the ports is already entangled, then disentangle it and the port that it was entangled with.

If those two previously entangled ports were the two ports of a MessageChannel object, then that MessageChannel object no longer represents an actual channel: the two ports in that object are no longer entangled.
Associate the two ports to be entangled, so that they form the two parts of a new channel. (There is no MessageChannel object that represents this channel.)

When the user agent is to clone a port original port, with the clone being owned by owner, it must run the following steps, which return a new MessagePort object. These steps must be run atomically.

Create a new MessagePort object owned by owner, and let new port be that object.
Move all the events in the port message queue of original port to the port message queue of new port, if any, leaving the new port's port message queue in its initial disabled state.
If the original port is entangled with another port, then run these substeps:
1. Let the remote port be the port with which the original port is entangled.
2. Entangle the remote port and new port objects. The original port object will be disentangled by this process.
Return new port. It is the clone.

The postMessage() method, when called on a port source port, must cause the user agent to run the following steps:

Let target port be the port with which source port is entangled, if any.
If the method was called with a second argument ports and that argument isn't null, then, if any of the entries in ports are null, if any MessagePort object is listed in ports more than once, if any of the MessagePort objects listed in ports have already been cloned once before, or if any of the entries in ports are either the source port or the target port (if any), then throw an INVALID_STATE_ERR exception.
If there is no target port (i.e. if source port is not entangled), then abort these steps.
Create an event that uses the MessageEvent interface, with the name message, which does not bubble, is not cancelable, and has no default action.
Let message be the method's first argument.
Let message clone be the result of obtaining a structured clone of message. If this throws an exception, then throw that exception and abort these steps.
Let the data attribute of the event have the value of message clone.
If the method was called with a second argument ports and that argument isn't null, then run the following substeps:
1. Let new ports be an empty array.
  
  For each port in ports in turn, obtain a new port by cloning the port with the owner of the target port as the owner of the clone, and append the clone to the new ports array.
  
  If the original ports array was empty, then the new ports array will also be empty.
2. Let the ports attribute of the event be the new ports array.
Add the event to the port message queue of target port.

The start() method must enable its port's port message queue, if it is not already enabled.

When a port's port message queue is enabled, the event loop must use it as one of its task sources.

If the Document of the port's event listeners' global object is not fully active, then the messages are lost.

The close() method, when called on a port local port that is entangled with another port, must cause the user agents to disentangle the two ports. If the method is called on a port that is not entangled, then the method must do nothing.

The following are the event handlers (and their corresponding event handler event types) that must be supported, as IDL attributes, by all objects implementing the MessagePort interface:

Event handler	Event handler event type
`onmessage`	`message`

The first time a MessagePort object's onmessage IDL attribute is set, the port's port message queue must be enabled, as if the start() method had been called.

4.3.1 Ports and garbage collection

When a MessagePort object o is entangled, user agents must either act as if o's entangled MessagePort object has a strong reference to o, or as if o's owner has a strong reference to o.

Thus, a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained.

Of course, if this was to occur on both sides of the channel, then both ports could be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other.

Furthermore, a MessagePort object must not be garbage collected while there exists a message in a task queue that is to be dispatched on that MessagePort object, or while the MessagePort object's port message queue is open and there exists a message event in that queue.

Authors are strongly encouraged to explicitly close MessagePort objects to disentangle them, so that their resources can be recollected. Creating many MessagePort objects and discarding them without closing them can lead to high memory usage.

References

All references are normative unless marked "Non-normative".

[DOMEVENTS]: Document Object Model (DOM) Level 3 Events Specification, D. Schepers. W3C.
[EVENTSOURCE]: Server-Sent Events, I. Hickson. W3C.
[HTML5]: HTML5, I. Hickson. W3C.
[WEBIDL]: Web IDL, C. McCormack. W3C.
[WEBSOCKET]: The WebSocket API, I. Hickson. W3C.

Acknowledgements

For a full list of acknowledgements, please see the HTML5 specification. [HTML5]