Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
The Push API provides webapps with scripted access to server-sent messages, for simplicity referred to here as push messages, as delivered by push services. A push service allows an application server to send messages to a webapp, regardless of whether the webapp is currently active on the user agent. The push message will be delivered to a Service Worker, which could then store the message's data or display a notification to the user.
This specification is designed to promote compatibility with any delivery method for push messages from push services to user agents.
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/.
This document was published by the Web Applications Working Group as a Working Draft.
This document is intended to become a W3C Recommendation.
If you wish to make comments regarding this document, please send them to
public-webapps@w3.org
(subscribe,
archives)
with [Push API] at the start of your email's subject.
All comments are welcome.
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.
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.
This document is governed by the 1 August 2014 W3C Process Document.
ServiceWorkerRegistration interface
PushManager interface
PushSubscription interface
PushMessageData interface
This section is non-normative.
As defined here, push services support delivery of application server messages in the following contexts and related use cases:
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, and SHOULD are to be interpreted as described in [RFC2119].
This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.
Implementations that use ECMAScript to implement the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL].
The terms event handler, event handler event type, queue a task, and fire a simple event are defined in [HTML5].
Promise,
and JSON.parse
are defined in [ECMASCRIPT].
EventInit,
DOMException,
AbortError,
InvalidStateError,
SecurityError,
NetworkError,
and steps for
constructing events are defined in [DOM].
The terms service
worker, service worker
registration, installing
worker, waiting worker,
and active
worker, and the types ServiceWorkerRegistration,
ServiceWorkerGlobalScope,
ExtendableEvent,
and ExtendableEventInit
are defined in [SERVICE-WORKERS].
The algorithms utf-8 encode, and utf-8 decode are defined in [ENCODING].
Any,
ArrayBuffer,
BufferSource,
and USVString are defined
in [WEBIDL].
The web push protocol describes a protocol that enables communication between a user agent or application server and a push service. Alternative protocols could be used in place of this protocol, but this specification assumes the use of this protocol; alternative protocols are expected to provide compatible semantics. Note: this is currently only a proposed protocol.
The term webapp refers to a Web application, i.e. an application implemented using Web technologies, and executing within the context of a Web user agent, e.g. a Web browser or other Web runtime environment.
The term application server refers to server-side components of a webapp.
A push message is data sent to a webapp from an application server.
A push message is delivered to the active worker associated with the push subscription to which the message was submitted. If the worker or its webapp is not currently running, the worker is started to enable delivery.
A push subscription is a message delivery context established between the user agent and the push service on behalf of a webapp, and associated with the webapp's service worker registration.
When a push subscription is deactivated, both the user agent and the push service MUST delete any stored copies of its details. Subsequent push messages for this push subscription MUST NOT be delivered.
A push subscription is deactivated when its associated service worker registration is unregistered, though a push subscription MAY be deactivated earlier.
A push subscription has an associated endpoint. It MUST be the absolute URL exposed by the push service where the application server can send push messages to. An endpoint MUST uniquely identify the push subscription.
The term push service refers to a system that allows application servers to send push messages to a webapp. A push service serves the endpoint or endpoints for the push subscriptions it serves.
The term express permission refers to an act by the user, e.g. via user interface or host device platform features, via which the user approves the permission of a webapp to access the Push API.
User agents MUST NOT provide Push API access to webapps without the express permission of the user. User agents MUST acquire consent for permission through a user interface
for each call to the subscribe() method, unless a previous permission grant
has been persisted, or a prearranged trust relationship applies. Permissions that are
preserved beyond the current browsing session MUST be revocable.
The user agent MAY consider the when
acquiring permission or determining the permission status.
PushSubscriptionOptions
When a permission is revoked, all push subscriptions created with that permission MUST be deactivated.
When a service worker registration is unregistered, any associated push subscription MUST be deactivated.
The endpoint of a deactivated push subscription MUST NOT be reused for a new push subscription. This prevents the creation of a persistent identifier that the user cannot remove. This also prevents reuse of the details of one push subscription to send push messages to another push subscription.
User agents MUST implement the Push API to be HTTPS-only. SSL-only support provides better protection for the user against man-in-the-middle attacks intended to obtain push subscription data. Browsers may ignore this rule for development purposes only.
This section is non-normative.
Although push services are expected to differ in deployment, a typical deployment is expected to have the following general entities and example operation for delivery of push messages:
This overall framework allows application servers to inform webapps that new data is available at the application server, or pass the new data directly to the webapp in the push message.
The push API enables delivery of arbitrary application data to webapps, and makes no assumptions about the over-the-air/wire protocol used by push services. As such, the details of what types of data flow through a push services for a particular webapp are specific to the push service and webapp. As needed, clarification about what data flows over-the-air/wire should be sought from push service operators or webapp developers.
The following code and diagram illustrate a hypothetical use of the push API.
This section is non-normative.
// https://example.com/serviceworker.js this.onpush = function(event) { console.log(event.data); // From here we can write the data to IndexedDB, send it to any open // windows, display a notification, etc. } // https://example.com/webapp.js navigator.serviceWorker.register('serviceworker.js').then( function(serviceWorkerRegistration) { serviceWorkerRegistration.pushManager.subscribe().then( function(pushSubscription) { console.log(pushSubscription.endpoint); // The push subscription details needed by the application // server are now available, and can be sent to it using, // for example, an XMLHttpRequest. }, function(error) { // During development it often helps to log errors to the // console. In a production environment it might make sense to // also report information about errors back to the // application server. console.log(error); } ); });
This section is non-normative.
A PushSubscription contains all the information needed to send a push
message. A push message can be delivered using the web push protocol.
The endpoint of a PushSubscription is a URI that allows
an application server to request delivery of a push message to a push
subscription.
ServiceWorkerRegistration interface
The Service Worker specification defines a ServiceWorkerRegistration interface
[SERVICE-WORKERS], which this specification extends.
partial interface ServiceWorkerRegistration {
readonly attribute PushManager pushManager;
};
The pushManager
attribute exposes a , which has an associated service
worker registration represented by the PushManager on
which the attribute is exposed.
ServiceWorkerRegistration
PushManager interface
The PushManager interface defines the operations to access push services.
interface PushManager {
Promise<PushSubscription> subscribe (optional PushSubscriptionOptions options);
Promise<PushSubscription?> getSubscription ();
Promise<PushPermissionState> permissionState (optional PushSubscriptionOptions options);
};
The subscribe
method when invoked MUST run the following steps:
Promise.
https, reject promise
with a DOMException whose name is "SecurityError"
and terminate these steps.
PushManager's associated
service worker registration.
DOMException whose
name is "InvalidStateError" and terminate these steps.
DOMException whose name is
"InvalidStateError" and terminate these steps.
DOMException whose
name is "PermissionDeniedError" and terminate these steps.
DOMException whose name is "AbortError" and
terminate these steps.
PushSubscription providing the details of the retrieved push
subscription.
DOMException
whose name is "AbortError" and terminate these steps.
PushSubscription providing the details of the new push
subscription.
The getSubscription
method when invoked MUST run the following steps:
Promise.
DOMException
whose name is "AbortError" and terminate these steps.
PushSubscription providing the details of the retrieved push
subscription.
The
permissionState method when invoked MUST run the following steps:
Promise.
PushPermissionState) of the
requesting webapp.
PushPermissionState providing the push permission status.
Permission to use the push service can be persistent, that is, it does not need to be reconfirmed for subsequent subscriptions if a valid permission exists.
If there is a need to ask for permission, it needs to be done by invoking the
subscribe method.
PushSubscriptionOptions dictionary
A PushSubscriptionOptions object represents additional options associated with a
push subscription. The user agent MAY consider these options when
requesting express permission from the user. When an option is considered, the
user agent SHOULD enforce it on incoming push
messages.
dictionary PushSubscriptionOptions {
boolean userVisibleOnly = false;
};
The userVisibleOnly option, when
set to true, indicates that the push subscription will only be used
for push messages whose effect is made visible to the user,
for example by displaying a Web Notification. [NOTIFICATIONS]
PushSubscription interface
A PushSubscription object represents a push subscription.
interface PushSubscription {
readonly attribute USVString endpoint;
Promise<boolean> unsubscribe ();
serializer = {attribute};
};
When getting the endpoint attribute, the
user agent MUST return the endpoint associated with the push
subscription.
The unsubscribe method when
invoked MUST run the following steps:
Promise.
false and terminate these steps.
NetworkError" exception and terminate these steps.
true.
PushMessageData interface
interface PushMessageData {
ArrayBuffer arrayBuffer ();
Blob blob ();
Any json ();
USVString text ();
};
PushMessageData objects have an associated bytes (a byte sequence) set on
creation.
The arrayBuffer()
method, when invoked, MUST return an ArrayBuffer whose contents are
bytes.
The blob() method, when
invoked, MUST return a Blob whose contents are bytes and
type is not provided.
The json() method, when invoked,
MUST return the result of invoking the initial value of JSON.parse with
the result of running utf-8 decode on bytes as argument. Re-throw any
exceptions thrown by JSON.parse.
The text() method, when
invoked, MUST return the result of running utf-8 decode on bytes.
typedef USVString PushMessageDataInit;
In future, PushMessageDataInit is likely to be a union type that includes types such
as Blob and BufferSource. The algorithm below would be extended, rather like the Fetch
standard's extract a byte
stream algorithm.
To extract a byte sequence from object, run these steps:
USVString
The Service Worker specification defines a ServiceWorkerGlobalScope interface
[SERVICE-WORKERS], which this specification extends.
partial interface ServiceWorkerGlobalScope {
attribute EventHandler onpush;
attribute EventHandler onpushsubscriptionchange;
};
The onpush attribute is
an event handler whose corresponding event handler event type is
push.
The onpushsubscriptionchange
attribute is an event handler whose corresponding event handler event type is
pushsubscriptionchange.
push event
The PushEvent interface represents a received push message.
dictionary PushEventInit : ExtendableEventInit {
PushMessageDataInit data;
};
[Constructor(DOMString type, optional PushEventInit eventInitDict), Exposed=ServiceWorker]
interface PushEvent : ExtendableEvent {
readonly attribute PushMessageData data;
};
Upon receiving a push message for a push subscription from the push service the user agent MUST run the following steps:
ServiceWorkerGlobalScope of the Service
Worker associated with the webapp.
PushEvent, whose
data attribute is a new PushMessageData with bytes set to the
binary message data received by the user agent in the push message, or an
empty byte sequence if no data was received.
push at scope.
When a constructor of the PushEvent interface, or of an interface that inherits
from the PushEvent interface, is invoked, the usual steps for constructing
events MUST be modified as follows: instead of setting the data
attribute of the event to the value of the eventInitDict's "data" member, set the data attribute to a
new PushMessageData with bytes set to the result of extracting a byte sequence from that dictionary member, or
an empty byte sequence if eventInitDict is not provided or has no
"data" member.
pushsubscriptionchange event
The pushsubscriptionchange event indicates that a push subscription
has been invalidated, or will soon be invalidated. For example, the push service
MAY set an expiration time. A webapp SHOULD attempt to resubscribe while handling
this event, in order to continue receiving push messages.
To fire a pushsubscriptionchange event, the user agent MUST run the
following steps:
ServiceWorkerGlobalScope of the Service
Worker associated with the webapp.
pushsubscriptionchange at scope.
enum PushPermissionState {
"granted",
"denied",
"prompt"
};
| Enumeration | Description |
|---|---|
granted
|
The webapp has permission to use the Push API. |
denied
|
The webapp has been denied permission to use the Push API. |
prompt
|
The webapp needs to ask for permission in order to use the Push API. |
The Push API uses the following new DOMException names.
| Name | Description |
|---|---|
PermissionDeniedError
|
The operation failed because the user denied permission to use the API. |
The editors would like to express their gratitude to the Mozilla and Telefónica Digital teams implementing the Firefox OS Push message solution and specially to Doug Turner, Nikhil Marathe, Fernando R. Sela, Guillermo López, Antonio Amaya, José Manuel Cantera and Albert Crespell, for their technical guidance, implementation work and support.