fix(service-worker): correctly determine client ID on navigation requests #42607
Conversation
|
You can preview be5e838 at https://pr42607-be5e838.ngbuilds.io/. |
gkalpak
force-pushed the
gkalpak:fix-sw-navigation-client-id
branch
from
be5e838
to
b18287d
|
You can preview b18287d at https://pr42607-b18287d.ngbuilds.io/. |
…ests The ServiceWorker assigns an app-version to a each client to ensure that all subsequent requests for a client are served using the same app-version. The assignment is done based on the client ID. Previously, the ServiceWorker would only try to read the client's ID off of the `FetchEvent`'s `clientId` property. However, for navigation requests the new client's ID will be set on [resultingClientId][1], while `clientId` will either be empty or hold the ID of the client where the request initiated from. See also related discussions in w3c/ServiceWorker#870 and w3c/ServiceWorker#1266. In theory, this could lead to the navigation request (i.e. `index.html`) being served from a different app-version than the subsequent sub-resource requests (i.e. assets). In practice, the likelihood of this happening is probably very low though, since it would require the latest app-version to be updated between the initial navigation request and the first sub-resource request, which should happen very shortly after the navigation request. This commit ensures that the correct client ID is determined even for navigation requests by also taking the `resultingClientId` property into account. [1]: https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/resultingClientId
gkalpak
force-pushed the
gkalpak:fix-sw-navigation-client-id
branch
from
b18287d
to
fac611a
|
You can preview fac611a at https://pr42607-fac611a.ngbuilds.io/. |
dylhunn
added a commit
that referenced
this pull request
Jun 22, 2021
…ests (#42607) The ServiceWorker assigns an app-version to a each client to ensure that all subsequent requests for a client are served using the same app-version. The assignment is done based on the client ID. Previously, the ServiceWorker would only try to read the client's ID off of the `FetchEvent`'s `clientId` property. However, for navigation requests the new client's ID will be set on [resultingClientId][1], while `clientId` will either be empty or hold the ID of the client where the request initiated from. See also related discussions in w3c/ServiceWorker#870 and w3c/ServiceWorker#1266. In theory, this could lead to the navigation request (i.e. `index.html`) being served from a different app-version than the subsequent sub-resource requests (i.e. assets). In practice, the likelihood of this happening is probably very low though, since it would require the latest app-version to be updated between the initial navigation request and the first sub-resource request, which should happen very shortly after the navigation request. This commit ensures that the correct client ID is determined even for navigation requests by also taking the `resultingClientId` property into account. [1]: https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/resultingClientId PR Close #42607
gkalpak
added a commit
to gkalpak/angular
that referenced
this pull request
Jul 5, 2021
Update `@angular/*` packages to latest 12.1.x versions (mainly to take advantage of recent ServiceWorker improvements, such as angular#42607 and angular#42622).
gkalpak
added a commit
to gkalpak/angular
that referenced
this pull request
Jul 5, 2021
Update `@angular/*` packages to latest 12.1.x versions (mainly to take advantage of recent ServiceWorker improvements, such as angular#42607 and angular#42622).
gkalpak
added a commit
to gkalpak/angular
that referenced
this pull request
Jul 7, 2021
Update `@angular/*` packages to latest 12.1.x versions (mainly to take advantage of recent ServiceWorker improvements, such as angular#42607 and angular#42622).
atscott
added a commit
that referenced
this pull request
Jul 7, 2021
atscott
added a commit
that referenced
this pull request
Jul 7, 2021
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
The ServiceWorker assigns an app-version to a each client to ensure that all subsequent requests for a client are served using the same app-version. The assignment is done based on the client ID.
Previously, the ServiceWorker would only try to read the client's ID off of the
FetchEvent'sclientIdproperty. However, for navigation requests the new client's ID will be set on resultingClientId, whileclientIdwill either be empty or hold the ID of the client where the request initiated from. See also related discussions in w3c/ServiceWorker#870 and w3c/ServiceWorker#1266.In theory, this could lead to the navigation request (i.e.
index.html) being served from a different app-version than the subsequent sub-resource requests (i.e. assets). In practice, the likelihood of this happening is probably very low though, since it would require the latest app-version to be updated between the initial navigation request and the first sub-resource request, which should happen very shortly after the navigation request.This commit ensures that the correct client ID is determined even for navigation requests by also taking the
resultingClientIdproperty into account.