395109817b
When the SW fetches URLs listed in a manifest with hashes, it checks the content hash against the manifest to make sure it has the correct version of the URL. In the event of a mismatch, the SW is supposed to consider the manifest invalid, and avoid using it. There are 3 cases to consider by which this can happen. Case 1: during the initial SW installation, a manifest is activated without waiting for every URL to be fully loaded. In the background, every prefetch URL listed by the manifest is requested and cached. One such prefetch request could fail the hash test, and cause the manifest to be treated as invalid. In such a case, the SW should enter a state of EXISTING_CLIENTS_ONLY, as the latest manifest is invalid. This case works today. Case 2: during the initial SW installation, as in Case 1, a manifest is activated without waiting for each URL to fully load. However, it's possible that the application could request a URL with a bad hash before background initialization tries to load that URL. This happens if, for example, the application has a broken index.html. In this case, the SW should enter a state of EXISTING_CLIENTS_ONLY, and serve the request from the network instead. What happens today is that the internal error escapes the SW and is returned as a rejected Promise to respondWith(), causing a browser-level error that the site cannot be loaded, breaking the site. This change allows the SW to detect the error and enter the correct state, falling back on the network if needed. Case 3: during checkForUpdate(), the SW will try to fully cache the new update before making it the latest version. Failure here is complicated - if the page fails to load due to transient network conditions (timeouts, 500s, etc), then it makes sense to continue serving the existing cached version, and attempt to activate the update on the next cycle. If the page fails due to non-transient conditions though (400 error, hash mismatch, etc), then the SW should consider the updated manifest invalid, and enter a state of EXISTING_CLIENTS_ONLY. Currently, all errors are treated as transient. This change causes the SW to treat all errors during updates as non-transient, which can cause the SW to unnecessarily enter a safe mode. A future change can allow the SW to remain in normal mode if the error is provably transient. PR Close #21288 |
||
|---|---|---|
| .. | ||
| animations | ||
| bazel | ||
| benchpress | ||
| common | ||
| compiler | ||
| compiler-cli | ||
| core | ||
| docs | ||
| examples | ||
| forms | ||
| http | ||
| language-service | ||
| platform-browser | ||
| platform-browser-dynamic | ||
| platform-server | ||
| platform-webworker | ||
| platform-webworker-dynamic | ||
| router | ||
| service-worker | ||
| upgrade | ||
| BUILD.bazel | ||
| README.md | ||
| empty.ts | ||
| es6-subset.d.ts | ||
| goog.d.ts | ||
| license-banner.txt | ||
| rollup.config.js | ||
| system.d.ts | ||
| tsconfig-build.json | ||
| tsconfig-metadata.json | ||
| tsconfig.json | ||
| types.d.ts | ||
README.md
Angular
The sources for this package are in the main Angular repo. Please file issues and pull requests against that repo.
License: MIT