Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification defines an API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS.
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 most recently formally published revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives) or whatwg@whatwg.org (subscribe, archives). All feedback is welcome.
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.
The latest stable version of the editor's draft of this specification is always available on the W3C CVS server. Change tracking for this document is available at the following location:
This specification is automatically generated from the corresponding section in the HTML5 specification's source document, as hosted in the WHATWG Subversion repository. Detailed change history for all of HTML5, including the parts that form this specification, can be found at the following locations:
The W3C Web Apps Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track. This specification is the 29 October 2009 Working Draft.
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.
EventSource
interfaceThis section is non-normative.
To enable servers to push data to Web pages over HTTP or using
dedicated server-push protocols, this specification introduces the
EventSource
interface.
Using this API consists of creating an EventSource
object and registering an event listener.
var source = new EventSource('updates.cgi'); source.onmessage = function (event) { alert(event.data); };
On the server-side, the script ("updates.cgi
" in this case) sends messages in the
following form, with the text/event-stream
MIME
type:
data: This is the first message. data: This is the second message, it data: has two lines. data: This is the third message.
All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.
Some conformance requirements are phrased as requirements on attributes, methods or objects. Such requirements are to be interpreted as requirements on user agents.
Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)
The only conformance class defined by this specification is user agents.
User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.
This specification relies on several other underlying specifications.
Many fundamental concepts from HTML5 are used by this specification. [HTML5]
The IDL blocks in this specification use the semantics of the WebIDL specification. [WEBIDL]
The construction "a Foo
object", where
Foo
is actually an interface, is sometimes
used instead of the more accurate "an object implementing the
interface Foo
".
The term DOM is used to refer to the API set made available to
scripts in Web applications, and does not necessarily imply the
existence of an actual Document
object or of any other
Node
objects as defined in the DOM Core
specifications. [DOMCORE]
An IDL attribute is said to be getting when its value is being retrieved (e.g. by author script), and is said to be setting when a new value is assigned to it.
EventSource
interface[Constructor(in DOMString url)] interface EventSource { readonly attribute DOMString URL; // ready state const unsigned short CONNECTING = 0; const unsigned short OPEN = 1; const unsigned short CLOSED = 2; readonly attribute unsigned short readyState; // networking attribute Function onopen; attribute Function onmessage; attribute Function onerror; void close(); }; EventSource implements EventTarget;
The EventSource(url)
constructor takes one argument,
url, which specifies the URL to
which to connect. When the EventSource()
constructor is
invoked, the UA must run these steps:
Resolve the URL specified in url, relative to the first script's base URL.
If the previous step failed, then throw a
SYNTAX_ERR
exception.
Return a new EventSource
object, and continue
these steps in the background (without blocking scripts).
Fetch the resource identified by the resulting absolute URL, from the first script's origin, and process it as described below.
The definition of the fetching algorithm is such that if the browser is already fetching the resource identified by the given absolute URL, that connection can be reused, instead of a new connection being established. All messages received up to this point are dispatched immediately, in this case.
This constructor must be visible when the script's global
object is either a Window
object or an object
implementing the WorkerUtils
interface.
The URL
attribute must return the absolute URL that resulted
from resolving the value that was
passed to the constructor.
The readyState
attribute represents the state of the connection. It can have the
following values:
CONNECTING
(numeric value 0)OPEN
(numeric value 1)CLOSED
(numeric value 2)close()
method was
invoked.When the object is created its readyState
must be set to
CONNECTING
(0). The
rules given below for handling the connection define when the value
changes.
The close()
method must close the connection, if any; must abort any
reconnection attempt, if any; and must set the readyState
attribute to
CLOSED
. If the
connection is already closed, 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 EventSource
interface:
Event handler | Event handler event type |
---|---|
onopen | open
|
onmessage | message
|
onerror | error
|
In addition to the above, each EventSource
object
has the following associated with it:
These values are not currently exposed on the interface.
The resource indicated in the argument to the EventSource
constructor is fetched when the constructor is run.
For HTTP connections, the Accept
header may
be included; if included, it must contain only formats of event
framing that are supported by the user agent (one of which must be
text/event-stream
, as described below).
If the event source's last event ID string is not the empty
string, then a Last-Event-ID
HTTP header must be included with the request, whose value is the
value of the event source's last event ID string.
User agents should use the Cache-Control: no-cache
header in requests to bypass any caches for requests of event
sources. User agents should ignore HTTP cache headers in the
response, never caching event sources.
User agents must act as if the connection had failed due to a
network error if the origin of the URL of
the resource to be fetched is not the
same origin as that of the first script
when the EventSource()
constructor is invoked.
As data is received, the tasks queued by the networking task source to handle the data must act as follows.
HTTP 200 OK responses with a Content-Type header
specifying the type text/event-stream
must be processed
line by line as described
below.
When a successful response with a supported MIME type is received, such that the user agent begins parsing the contents of the stream, the user agent must announce the connection.
If such a resource (with the correct MIME type) completes loading (i.e. either the entire HTTP response body is received, or the connection is closed somehow, whether by the server or by a network error), the user agent must reset the connection. This doesn't apply for the error cases that are listed below.
HTTP 200 OK responses that have a Content-Type other
than text/event-stream
(or some other supported type)
must cause the user agent to fail the connection.
HTTP 204 No Content, and 205 Reset Content responses are equivalent to 200 OK responses with the right MIME type but no content, and thus must reset the connection.
Other HTTP response codes in the 2xx range must similarly reset the connection. They are, however, likely to indicate an error has occurred somewhere and may cause the user agent to emit a warning.
HTTP 301 Moved Permanently responses must cause the user agent to
reconnect using the new server specified URL instead of the
previously specified URL for all subsequent requests for this event
source. (It doesn't affect other EventSource
objects
with the same URL unless they also receive 301 responses, and it
doesn't affect future sessions, e.g. if the page is reloaded.)
HTTP 302 Found, 303 See Other, and 307 Temporary Redirect responses must cause the user agent to connect to the new server-specified URL, but if the user agent needs to again request the resource at a later point, it must return to the previously specified URL for this event source.
The Origin specification also introduces some relevant requirements when dealing with redirects. [ORIGIN]
HTTP 305 Use Proxy, HTTP 401 Unauthorized, and 407 Proxy Authentication Required should be treated transparently as for any other subresource.
Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection.
For non-HTTP protocols, UAs should act in equivalent ways.
When a user agent is to announce the connection, the
user agent must set the readyState
attribute to
OPEN
and queue a
task to fire a simple event named open
at the
EventSource
object.
When a user agent is to reset the connection, the user
agent must set the readyState
attribute to
CONNECTING
,
queue a task to fire a simple event named
error
at the
EventSource
object, and then fetch the
event source resource again after a delay equal to the reconnection
time of the event source, from the same origin as the
original request triggered by the EventSource()
constructor. Only if the user agent resets the connection does the connection get
opened anew!
When a user agent is to fail the connection, the user
agent must set the readyState
attribute to
CLOSED
and queue a
task to fire a simple event named error
at the EventSource
object. Once the user agent has failed the connection, it does not
attempt to reconnect!
The task source for any tasks that are queued by EventSource
objects is the
remote event task source.
This event stream format's MIME type is
text/event-stream
.
The event stream format is as described by the stream
production of the following ABNF, the
character set for which is Unicode. [ABNF]
stream = [ bom ] *event event = *( comment / field ) end-of-line comment = colon *any-char end-of-line field = 1*name-char [ colon [ space ] *any-char ] end-of-line end-of-line = ( cr lf / cr / lf / eof ) eof = < matches repeatedly at the end of the stream > ; characters lf = %x000A ; U+000A LINE FEED (LF) cr = %x000D ; U+000D CARRIAGE RETURN (CR) space = %x0020 ; U+0020 SPACE colon = %x003A ; U+003A COLON (:) bom = %xFEFF ; U+FEFF BYTE ORDER MARK name-char = %x0000-0009 / %x000B-000C / %x000E-0039 / %x003B-10FFFF ; a Unicode character other than U+000A LINE FEED (LF), U+000D CARRIAGE RETURN (CR), or U+003A COLON (:) any-char = %x0000-0009 / %x000B-000C / %x000E-10FFFF ; a Unicode character other than U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR)
Event streams in this format must always be encoded as UTF-8.
Lines must be separated by either a U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pair, a single U+000A LINE FEED (LF) character, or a single U+000D CARRIAGE RETURN (CR) character.
Since connections established to remote servers for such resources are expected to be long-lived, UAs should ensure that appropriate buffering is used. In particular, while line buffering with lines are defined to end with a single U+000A LINE FEED (LF) character is safe, block buffering or line buffering with different expected line endings can cause delays in event dispatch.
Bytes or sequences of bytes that are not valid UTF-8 sequences must be interpreted as the U+FFFD REPLACEMENT CHARACTER.
One leading U+FEFF BYTE ORDER MARK character must be ignored if any are present.
The stream must then be parsed by reading everything line by line, with a U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pair, a single U+000A LINE FEED (LF) character not preceded by a U+000D CARRIAGE RETURN (CR) character, a single U+000D CARRIAGE RETURN (CR) character not followed by a U+000A LINE FEED (LF) character, and the end of the file being the four ways in which a line can end.
When a stream is parsed, a data buffer and an event name buffer must be associated with it. They must be initialized to the empty string
Lines must be processed, in the order they are received, as follows:
Dispatch the event, as defined below.
Ignore the line.
Collect the characters on the line before the first U+003A COLON character (:), and let field be that string.
Collect the characters on the line after the first U+003A COLON character (:), and let value be that string. If value starts with a single U+0020 SPACE character, remove it from value.
Process the field using the steps described below, using field as the field name and value as the field value.
Process the field using the steps described below, using the whole line as the field name, and the empty string as the field value.
Once the end of the file is reached, the user agent must dispatch the event one final time, as defined below.
The steps to process the field given a field name and a field value depend on the field name, as given in the following list. Field names must be compared literally, with no case folding performed.
Set the event name buffer to field value.
Append the field value to the data buffer, then append a single U+000A LINE FEED (LF) character to the data buffer.
Set the event stream's last event ID to the field value.
If the field value consists of only characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then interpret the field value as an integer in base ten, and set the event stream's reconnection time to that integer. Otherwise, ignore the field.
The field is ignored.
When the user agent is required to dispatch the event, then the user agent must act as follows:
If the data buffer is an empty string, set the data buffer and the event name buffer to the empty string and abort these steps.
If the data buffer's last character is a U+000A LINE FEED (LF) character, then remove the last character from the data buffer.
If the event name buffer is not the empty string but is also not a valid event type name, as defined by the DOM Events specification, set the data buffer and the event name buffer to the empty string and abort these steps. [DOMEVENTS]
Otherwise, 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 the data buffer, the origin
attribute must be set
to the Unicode
serialization of the origin of the event
stream's URL, and the lastEventId
attribute
must be set to the last event ID
string of the event source.
If the event name buffer has a value other than the empty string, change the type of the newly created event to equal the value of the event name buffer.
Set the data buffer and the event name buffer to the empty string.
Queue a task to dispatch the newly created
event at the EventSource
object.
If an event doesn't have an "id" field, but an
earlier event did set the event source's last event ID
string, then the event's lastEventId
field will
be set to the value of whatever the last seen "id" field was.
The following event stream, once followed by a blank line:
data: YHOO data: +2 data: 10
...would cause an event message
with the interface
MessageEvent
to be dispatched on the
EventSource
object. The event's data
attribute would contain
the string YHOO\n+2\n10
(where \n
represents a newline).
This could be used as follows:
var stocks = new EventSource("http://stocks.example.com/ticker.php"); stocks.onmessage = function (event) { var data = event.data.split('\n'); updateStocks(data[0], data[1], data[2]); };
...where updateStocks()
is a function defined as:
function updateStocks(symbol, delta, value) { ... }
...or some such.
The following stream contains four blocks. The first block has
just a comment, and will fire nothing. The second block has two
fields with names "data" and "id" respectively; an event will be
fired for this block, with the data "first event", and will then
set the last event ID to "1" so that if the connection died between
this block and the next, the server would be sent a Last-Event-ID
header with the
value "1". The third block fires an event with data "second event",
and also has an "id" field, this time with no value, which resets
the last event ID to the empty string (meaning no Last-Event-ID
header will now be
sent in the event of a reconnection being attempted). Finally, the
last block just fires an event with the data "third event". Note
that the last block doesn't have to end with a blank line, the end
of the stream is enough to trigger the dispatch of the last
event.
: test stream data: first event id: 1 data: second event id data: third event
The following stream fires just one event:
data data data data:
The first and last blocks do nothing, since they do not contain any actual data (the data buffer remains at the empty string, and so nothing gets dispatched). The middle block fires an event with the data set to a single newline character.
The following stream fires two identical events:
data:test data: test
This is because the space after the colon is ignored if present.
Legacy proxy servers are known to, in certain cases, drop HTTP connections after a short timeout. To protect against such proxy servers, authors can include a comment line (one starting with a ':' character) every 15 seconds or so.
Authors wishing to relate event source connections to each other or to specific documents previously served might find that relying on IP addresses doesn't work, as individual clients can have multiple IP addresses (due to having multiple proxy servers) and individual IP addresses can have multiple clients (due to sharing a proxy server). It is better to include a unique identifier in the document when it is served and then pass that identifier as part of the URL when the connection is established.
Authors are also cautioned that HTTP chunking can have unexpected negative effects on the reliability of this protocol. Where possible, chunking should be disabled for serving event streams unless the rate of messages is high enough for this not to matter.
Implementations that support HTTP's per-server connection
limitation might run into trouble when opening multiple pages from a
site if each page has an EventSource
to the same
domain. Authors can avoid this using the relatively complex
mechanism of using unique domain names per connection, or by
allowing the user to enable or disable the EventSource
functionality on a per-page basis, or by sharing a single
EventSource
object using a shared worker. [WEBWORKERS]
Other formats of event framing may also be supported in addition
to text/event-stream
, but this specification does not
define how they are to be parsed or processed.
Such formats could include systems like SMS-push;
for example servers could use Accept
headers
and HTTP redirects to an SMS-push mechanism as a kind of protocol
negotiation to reduce network load in GSM environments.
While an EventSource
object's readyState
is not CLOSED
, and the object has one
or more event listeners registered for message
events, there must be a strong
reference from the Window
or WorkerUtils
object that the EventSource
object's constructor was
invoked from to the EventSource
object itself.
If an EventSource
object is garbage collected while
its connection is still open, the connection must be closed.
text/event-stream
This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.
An event stream from an origin distinct from the origin of the content consuming the event stream can result in information leakage. To avoid this, user agents are required to block all cross-origin loads.
Event streams can overwhelm a user agent; a user agent is expected to apply suitable restrictions to avoid depleting local resources because of an overabundance of information from an event stream.
Servers can be overwhelmed if a situation develops in which the server is causing clients to reconnect rapidly. Servers should use a 5xx status code to indicate capacity problems, as this will prevent conforming clients from reconnecting automatically.
Fragment identifiers have no meaning with
text/event-stream
resources.
Last-Event-ID
This section describes a header field for registration in the Permanent Message Header Field Registry. [RFC3864]
All references are normative unless marked "Non-normative".