|
59 | 59 | <body data-cite="service-workers FILEAPI promises-guide">
|
60 | 60 | <section id="abstract">
|
61 | 61 | <p>
|
62 |
| - The <cite>Push API</cite> enables sending of a <a>push message</a> to a <a>webapp</a> via a |
63 |
| - <a>push service</a>. An <a>application server</a> can send a <a>push message</a> at any |
64 |
| - time, even when a <a>webapp</a> or <a>user agent</a> is inactive. The <a>push service</a> |
| 62 | + The <cite>Push API</cite> enables sending of a <a>push message</a> to a web application via |
| 63 | + a <a>push service</a>. An <a>application server</a> can send a <a>push message</a> at any |
| 64 | + time, even when a web application or <a>user agent</a> is inactive. The <a>push service</a> |
65 | 65 | ensures reliable and efficient delivery to the <a>user agent</a>. <a>Push messages</a> are
|
66 |
| - delivered to a <a>Service Worker</a> that runs in the origin of the <a>webapp</a>, which |
| 66 | + delivered to a <a>Service Worker</a> that runs in the origin of the web application, which |
67 | 67 | can use the information in the message to update local state or display a notification to
|
68 | 68 | the user.
|
69 | 69 | </p>
|
|
78 | 78 | Introduction
|
79 | 79 | </h2>
|
80 | 80 | <p>
|
81 |
| - The Push API allows a <a>webapp</a> to communicate with a <a>user agent</a> asynchronously. |
82 |
| - This allows an <a>application server</a> to provide the <a>user agent</a> with |
83 |
| - time-sensitive information whenever that information becomes known, rather than waiting for |
84 |
| - a user to open the <a>webapp</a>. |
| 81 | + The Push API allows a web application to communicate with a <a>user agent</a> |
| 82 | + asynchronously. This allows an <a>application server</a> to provide the <a>user agent</a> |
| 83 | + with time-sensitive information whenever that information becomes known, rather than |
| 84 | + waiting for a user to open the web application. |
85 | 85 | </p>
|
86 | 86 | <p>
|
87 | 87 | As defined here, <a>push services</a> support delivery of <a>push messages</a> at any time.
|
88 | 88 | </p>
|
89 | 89 | <p>
|
90 |
| - In particular, a <a>push message</a> will be delivered to the <a>webapp</a> even if that |
91 |
| - <a>webapp</a> is not currently active in a browser window: this relates to use cases in |
92 |
| - which the user may close the <a>webapp</a>, but still benefits from the <a>webapp</a> being |
93 |
| - able to be restarted when a <a>push message</a> is received. For example, a <a>push |
| 90 | + In particular, a <a>push message</a> will be delivered to the web application even if that |
| 91 | + web application is not currently active in a browser window: this relates to use cases in |
| 92 | + which the user may close the web application, but still benefits from the web application |
| 93 | + being able to be restarted when a <a>push message</a> is received. For example, a <a>push |
94 | 94 | message</a> might be used to inform the user of an incoming WebRTC call.
|
95 | 95 | </p>
|
96 | 96 | <p>
|
97 | 97 | A <a>push message</a> can also be sent when the <a>user agent</a> is temporarily offline.
|
98 | 98 | In support of this, the <a>push service</a> stores messages for the <a>user agent</a> until
|
99 |
| - the <a>user agent</a> becomes available. This supports use cases where a <a>webapp</a> |
| 99 | + the <a>user agent</a> becomes available. This supports use cases where a web application |
100 | 100 | learns of changes that occur while a user is offline and ensures that the <a>user agent</a>
|
101 | 101 | can be provided with relevant information in a timely fashion. <a>Push messages</a> are
|
102 | 102 | stored by the <a>push service</a> until the <a>user agent</a> becomes reachable and the
|
103 | 103 | message can be delivered.
|
104 | 104 | </p>
|
105 | 105 | <p>
|
106 | 106 | The Push API will also ensure reliable delivery of push messages while a <a>user agent</a>
|
107 |
| - is actively using a <a>webapp</a>, for instance if a user is actively using the |
108 |
| - <a>webapp</a> or the <a>webapp</a> is in active communication with an <a>application |
| 107 | + is actively using a web application, for instance if a user is actively using the web |
| 108 | + application or the web application is in active communication with an <a>application |
109 | 109 | server</a> through an active worker, frame, or background window. This is not the primary
|
110 |
| - use case for the Push API. A <a>webapp</a> might choose to use the Push API for infrequent |
111 |
| - messages to avoid having to maintain constant communications with the <a>application |
112 |
| - server</a>. |
| 110 | + use case for the Push API. A web application might choose to use the Push API for |
| 111 | + infrequent messages to avoid having to maintain constant communications with the |
| 112 | + <a>application server</a>. |
113 | 113 | </p>
|
114 | 114 | <p>
|
115 | 115 | Push messaging is best suited to occasions where there is not already an active
|
116 |
| - communications channel established between <a>user agent</a> and <a>webapp</a>. Sending |
| 116 | + communications channel established between <a>user agent</a> and web application. Sending |
117 | 117 | <a>push messages</a> requires considerably more resources when compared with more direct
|
118 | 118 | methods of communication such as [[[fetch]]] or <a data-cite=
|
119 | 119 | "html/web-sockets.html#network">websockets</a>. <a>Push messages</a> usually have higher
|
@@ -149,24 +149,19 @@ <h2>
|
149 | 149 | </h2>
|
150 | 150 | <section>
|
151 | 151 | <h2>
|
152 |
| - Webapp |
| 152 | + Application server |
153 | 153 | </h2>
|
154 | 154 | <p>
|
155 |
| - The term <dfn>webapp</dfn> refers to a Web application, i.e. an application implemented |
156 |
| - using Web technologies, and executing within the context of a Web <a>user agent</a>, e.g. |
157 |
| - a Web browser or other Web runtime environment. |
158 |
| - </p> |
159 |
| - <p> |
160 |
| - The term <dfn>application server</dfn> refers to server-side components of a |
161 |
| - <a>webapp</a>. |
| 155 | + The term <dfn>application server</dfn> refers to server-side components of a web |
| 156 | + application. |
162 | 157 | </p>
|
163 | 158 | </section>
|
164 | 159 | <section>
|
165 | 160 | <h2>
|
166 | 161 | Push message
|
167 | 162 | </h2>
|
168 | 163 | <p>
|
169 |
| - A <dfn>push message</dfn> is data sent to a <a>webapp</a> from an <a>application |
| 164 | + A <dfn>push message</dfn> is data sent to a web application from an <a>application |
170 | 165 | server</a>.
|
171 | 166 | </p>
|
172 | 167 | <p>
|
|
181 | 176 | </h2>
|
182 | 177 | <p>
|
183 | 178 | A <dfn>push subscription</dfn> is a message delivery context established between the
|
184 |
| - <a>user agent</a> and the <a>push service</a> on behalf of a <a>webapp</a>. Each <a>push |
185 |
| - subscription</a> is associated with a <a>service worker registration</a> and a <a>service |
186 |
| - worker registration</a> has at most one <a>push subscription</a>. |
| 179 | + <a>user agent</a> and the <a>push service</a> on behalf of a web application. Each |
| 180 | + <a>push subscription</a> is associated with a <a>service worker registration</a> and a |
| 181 | + <a>service worker registration</a> has at most one <a>push subscription</a>. |
187 | 182 | </p>
|
188 | 183 | <p>
|
189 | 184 | A <a>push subscription</a> has an associated <dfn>push endpoint</dfn>. It MUST be the
|
|
302 | 297 | </h2>
|
303 | 298 | <p>
|
304 | 299 | The term <dfn data-lt="push services">push service</dfn> refers to a system that allows
|
305 |
| - <a>application servers</a> to send <a>push messages</a> to a <a>webapp</a>. A push |
| 300 | + <a>application servers</a> to send <a>push messages</a> to a web application. A push |
306 | 301 | service serves the <a>push endpoint</a> or <a data-lt="push endpoints">endpoints</a> for
|
307 | 302 | the <a>push subscriptions</a> it serves.
|
308 | 303 | </p>
|
|
322 | 317 | <p>
|
323 | 318 | The term <dfn>express permission</dfn> refers to an act by the user, e.g. via user
|
324 | 319 | interface or host device platform features, via which the user approves the use of the
|
325 |
| - Push API by the <a>webapp</a>. |
| 320 | + Push API by the web application. |
326 | 321 | </p>
|
327 | 322 | </section>
|
328 | 323 | </section>
|
|
340 | 335 | </p>
|
341 | 336 | <p>
|
342 | 337 | There is no guarantee that a <a>push message</a> was sent by an <a>application server</a>
|
343 |
| - having the same origin as the <a>webapp</a>. The <a>application server</a> is able to share |
344 |
| - the details necessary to use a <a>push subscription</a> with a third party at its own |
| 338 | + having the same origin as the web application. The <a>application server</a> is able to |
| 339 | + share the details necessary to use a <a>push subscription</a> with a third party at its own |
345 | 340 | discretion.
|
346 | 341 | </p>
|
347 | 342 | <p>
|
|
350 | 345 | <a>application server</a>'s communication with the user.
|
351 | 346 | </p>
|
352 | 347 | <p>
|
353 |
| - <a>User agents</a> MUST NOT provide Push API access to <a>webapps</a> without the |
| 348 | + <a>User agents</a> MUST NOT provide Push API access to web applications without the |
354 | 349 | <a>express permission</a> of the user. <a>User agents</a> MUST acquire consent for
|
355 | 350 | permission through a user interface for each call to the `subscribe()` method, unless a
|
356 | 351 | previous permission grant has been persisted, or a prearranged trust relationship applies.
|
|
360 | 355 | The Push API may have to wake up the Service Worker associated with the <a>service worker
|
361 | 356 | registration</a> in order to run the developer-provided event handlers. This can cause
|
362 | 357 | resource usage, such as network traffic, that the <a>user agent</a> SHOULD attribute to the
|
363 |
| - <a>webapp</a> that created the <a>push subscription</a>. |
| 358 | + web application that created the <a>push subscription</a>. |
364 | 359 | </p>
|
365 | 360 | <p>
|
366 | 361 | The <a>user agent</a> MAY consider the <a>PushSubscriptionOptions</a> when acquiring
|
|
401 | 396 | Push Framework
|
402 | 397 | </h2>
|
403 | 398 | <p>
|
404 |
| - A <a>push message</a> is sent from an <a>application server</a> to a <a>webapp</a> as |
| 399 | + A <a>push message</a> is sent from an <a>application server</a> to a web application as |
405 | 400 | follows:
|
406 | 401 | </p>
|
407 | 402 | <ul>
|
|
419 | 414 | <p>
|
420 | 415 | This overall framework allows <a>application servers</a> to activate a <a>Service
|
421 | 416 | Worker</a> in response to events at the <a>application server</a>. Information about those
|
422 |
| - events can be included in the <a>push message</a>, which allows the <a>webapp</a> to react |
423 |
| - appropriately to those events, potentially without needing to initiate network requests. |
| 417 | + events can be included in the <a>push message</a>, which allows the web application to |
| 418 | + react appropriately to those events, potentially without needing to initiate network |
| 419 | + requests. |
424 | 420 | </p>
|
425 | 421 | <p>
|
426 | 422 | The following code and diagram illustrate a hypothetical use of the push API.
|
|
484 | 480 | <ul>
|
485 | 481 | <li>The <a data-lt="PushSubscription.endpoint">push endpoint</a> of a
|
486 | 482 | <a>PushSubscription</a> is a URL that allows an <a>application server</a> to request
|
487 |
| - delivery of a <a>push message</a> to a <a>webapp</a>. |
| 483 | + delivery of a <a>push message</a> to a web application. |
488 | 484 | </li>
|
489 | 485 | <li data-link-for="PushSubscription">The {{getKey()}} method on a <a>PushSubscription</a>
|
490 | 486 | is used to retrieve keying material used to encrypt and authenticate <a>push
|
|
590 | 586 | <li>If <var>registration</var>'s <a>active worker</a> is null, reject <var>promise</var>
|
591 | 587 | with a {{DOMException}} whose name is "{{InvalidStateError}}" and terminate these steps.
|
592 | 588 | </li>
|
593 |
| - <li>Ask the user whether they allow the <a>webapp</a> to receive <a>push messages</a>, |
| 589 | + <li>Ask the user whether they allow the web application to receive <a>push messages</a>, |
594 | 590 | unless a prearranged trust relationship applies or the user has already granted or denied
|
595 |
| - permission explicitly for this <a>webapp</a>. Note that a <a>user agent</a> that needs to |
| 591 | + permission explicitly for this web application. Note that a <a>user agent</a> that needs to |
596 | 592 | request permission might be unable to do so if <a data-link-for="PushManager">subscribe</a>
|
597 | 593 | is invoked from a service worker, in which case permission will be denied automatically.
|
598 | 594 | </li>
|
|
659 | 655 | </li>
|
660 | 656 | <li>Return <var>promise</var> and continue the following steps asynchronously.
|
661 | 657 | </li>
|
662 |
| - <li>Retrieve the push permission status (<a>PushPermissionState</a>) of the requesting <a> |
663 |
| - webapp</a>. |
| 658 | + <li>Retrieve the push permission status (<a>PushPermissionState</a>) of the requesting web |
| 659 | + application. |
664 | 660 | </li>
|
665 | 661 | <li>If there is an error, reject <var>promise</var> with no arguments and terminate these
|
666 | 662 | steps.
|
|
926 | 922 | <dfn>PushEncryptionKeyName</dfn> enumeration
|
927 | 923 | </h2>
|
928 | 924 | <p>
|
929 |
| - Encryption keys used for <a>push message</a> encryption are provided to a <a>webapp</a> |
| 925 | + Encryption keys used for <a>push message</a> encryption are provided to a web application |
930 | 926 | through the <a data-link-for="PushSubscription">getKey</a> method or the serializer of
|
931 | 927 | <a>PushSubscription</a>. Each key is named using a value from the
|
932 | 928 | <a>PushEncryptionKeyName</a> enumeration.
|
@@ -1249,7 +1245,7 @@ <h2>
|
1249 | 1245 | The <dfn>newSubscription</dfn> member details the <a>push subscription</a> that is
|
1250 | 1246 | valid per invocation of the <a>pushsubscriptionchange</a> event. The value will be
|
1251 | 1247 | `null` when no new <a>push subscription</a> could be established, for example because
|
1252 |
| - the <a>webapp</a> has lost <a>express permission</a>. |
| 1248 | + the web application has lost <a>express permission</a>. |
1253 | 1249 | </p>
|
1254 | 1250 | <p>
|
1255 | 1251 | The <dfn>oldSubscription</dfn> member details the <a>push subscription</a> that SHOULD
|
@@ -1284,23 +1280,23 @@ <h2>
|
1284 | 1280 | <dfn>granted</dfn>
|
1285 | 1281 | </td>
|
1286 | 1282 | <td>
|
1287 |
| - The <a>webapp</a> has permission to use the Push API. |
| 1283 | + The web application has permission to use the Push API. |
1288 | 1284 | </td>
|
1289 | 1285 | </tr>
|
1290 | 1286 | <tr>
|
1291 | 1287 | <td>
|
1292 | 1288 | <dfn>denied</dfn>
|
1293 | 1289 | </td>
|
1294 | 1290 | <td>
|
1295 |
| - The <a>webapp</a> has been denied permission to use the Push API. |
| 1291 | + The web application has been denied permission to use the Push API. |
1296 | 1292 | </td>
|
1297 | 1293 | </tr>
|
1298 | 1294 | <tr>
|
1299 | 1295 | <td>
|
1300 | 1296 | <dfn>prompt</dfn>
|
1301 | 1297 | </td>
|
1302 | 1298 | <td>
|
1303 |
| - The <a>webapp</a> needs to ask for permission in order to use the Push API. |
| 1299 | + The web application needs to ask for permission in order to use the Push API. |
1304 | 1300 | </td>
|
1305 | 1301 | </tr>
|
1306 | 1302 | </table>
|
|
0 commit comments