1. Introduction

A service worker is capable of fetching and caching assets, the size of which is restricted only by origin storage. However, if the user navigates away from the site or closes the browser, the service worker is likely to be killed. This can happen even if there’s a pending promise passed to waitUntil() - if it hasn’t resolved within a few minutes the browser may consider it an abuse of service worker and kill the process.

This is excellent for battery and privacy, but it makes it difficult to download and cache large assets such as podcasts and movies, and upload video and images.

This specification aims to:

Allow fetches (requests & responses) to continue even if the user closes all windows & workers to the origin.

Allow a single job to involve many requests, as defined by the app.

Allow the browser/OS to show UI to indicate the progress of that job, and allow the user to pause/abort.

Allow the browser/OS to deal with poor connectivity by pausing/resuming the download.

Allow the app to react to success/failure of the job, perhaps by caching the results.

Note: This handles a race condition where abort() was successfully called but one of the fetches failed at the same time. If we’ve returned true from abort(), this ensures we fire the related abort event.

Note: This algorithm manages the fetching of a background fetch record. One instance of this algorithm is started per background fetch record, but it is called recursively to retry fetches or to fetch the next part of a partial response.

Note: This algorithm checks if a partial response reasonably matches what was requested, and optionally checks if it should be combined with a previous response.

To validate a partial response for an expectedRangeStart (a number), a partialResponse (a response), and an optional previousResponse (a response or null, null unless otherwise specified), run these steps:

Let previousResponseFirstBytePos, previousResponseLastBytePos, and previousResponseCompleteLength be the result of extracting content-range values from previousResponse. If this fails, then return invalid.

If previousResponseCompleteLength is not null, and responseCompleteLength does not equal previousResponseCompleteLength, then return invalid.

Note: This algorithm creates platform objects for background fetch records. It also manages the streaming of the response from the stored bytes. The background fetch operation may still be in progress at this point.

8. Privacy and bandwidth usage

Fetches can be large and take a long time to complete. During this time the user will be fetching data from one or more servers. The user’s IP address, which may change during the operation, could be used to track the user’s location over time.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
in the normative parts of this document
are to be interpreted as described in RFC 2119.
However, for readability,
these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative
except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note”
and are set apart from the normative text with class="note", like this: