feat(service-worker): add support for ignoring specific URLs #23025

gkalpak · 2018-03-27T15:56:28Z

PR Checklist

The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
Tests for the changes have been added (for bug fixes / features)
Docs have been added / updated (for bug fixes / features)

PR Type

[x] Feature

What is the current behavior?

The ServiceWorker will redirect navigation requests that don't match any asset or data group to the specified index file. Yet, sometimes it is desirable to configure the SW to ignore specific URLs (even for navigation requests) and pass them through to the server.

Issue Number: #20404

What is the new behavior?

This commit adds support for specifying an optional ignoredUrlPatterns list in ngsw-config.json, which contains URLs or simple globs (currently only recognizing * and **). Requests matching these URLs or patterns will not be handled by the SW.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Fixes #20404.

mary-poppins · 2018-03-27T16:04:33Z

You can preview 3e4e220 at https://pr23025-3e4e220.ngbuilds.io/.

gkalpak · 2018-03-27T16:05:01Z

TODOs

Update the SW Config guide.

TODECIDEs

Should matching be case-insensitive?
Does it make a difference or are URLs always lowercased by the browser for example?
For reference, matching is case-sensitive in other places, such as asset-/data-groups.

Matching will remain case-sensitive for now. This is consistent with other similar places.
Do we need to support negated patterns?
This would slightly complicate the implementation.
Since ignored URLs should be the minority, not the norm, I think not supporting negated patterns is probably fine.

Let's not support negative patterns for now. We can revisit once/if it turns out to be a needed feature.
Do we want to support RegExps (instead of or in addition to globs)?
The basic globbing we provide now is too limiting (and can be confusing for people expecting full glob support).
I would love for us to support RegExps 🙏

I guess we are not supporting RegExps for the time being. 😞
Do we want to support not handling such requests at all (i.e. do not call event.respondWith(...) at all)?
Right now we do scope.fetch(...), which (a) shows up as if the SW did handle the request and (b) is subject to SW limitations.
See Failed to load HTTP resource in live URL #23012 for a usecase.

Not possible. See feat(service-worker): add support for ignoring specific URLs #23025 (comment).

cc @alxhub

alxhub · 2018-03-27T20:23:58Z

Nice work!

I don't think we can support not handling such requests at all (not calling respondWith).

This is because we could possibly be in a mode where we were just started, and need to fetch the manifest/etc from cache to figure out how to handle the request. Since this can only happen asynchronously and skipping respondWith is a synchronous decision, we must always respondWith in this case.

gkalpak · 2018-03-27T20:52:33Z

Oh, I didn't know .respondWith() should be called synchronously 😞

mary-poppins · 2018-03-28T15:31:52Z

You can preview 9e6edca at https://pr23025-9e6edca.ngbuilds.io/.

gkalpak · 2018-03-28T16:00:47Z

Updated the public API (needs approval), fixed up tests and updated the SW Config guide.
PTAL

mary-poppins · 2018-03-28T16:01:40Z

You can preview 7f2155e at https://pr23025-7f2155e.ngbuilds.io/.

gkalpak · 2018-03-30T10:01:02Z

@coryrylan wrote (in #20404 (comment)):

Would a list of regexes be more flexible?
Workbox has a navigateFallbackWhitelist and navigateFallbackBlacklist properies to take a list of regexes to scope the service worker to. This is actually the feature that is keeping us on Workbox instead of migrating to @angular/service-worker. We use navigateFallbackWhitelist to only apply to the angular specific pages as we are converting a large enterprise app.

https://developers.google.com/web/tools/workbox/modules/workbox-build

gkalpak · 2018-03-30T10:14:58Z

I would love to have regexp support (as stated in #23025 (comment) 😁).

Things to consider:

Supporting only regexps , while other places support only globs, will be confusing (from a public API standpoint).
Supporting both globs and regexps, will require a way to differentiate which is used (because both can look similar).
Solutions (off the top of my head):
1. {type: 'regex', pattern: '...'} vs {type: 'glob', pattern: '...'}.
  Pros: Clear. Extensible (e.g. we can easily add more types in the future (prefix', full`)).
  Cons: Verbose.
2. 're:...' vs glob:....
  Pros: Somewhat clear. Somewhat extensible. Somewhat not verbose.
  Cons: Somewhat idiomatic. Not as much extensible. Slightly more verbose.

@alxhub, WDYT?

IgorMinar

lgtm for public api changes

gkalpak · 2018-04-05T07:28:35Z

For future reference:
Discussed this with @alxhub and decided to implement the following:

Use one list for both positive and negative matches (more inline with the rest of the APIs). No RegExps for now.
Look into improving our globbing support (in a follow-up PR). Could build on top of aio/tools/firebase-test-utils/FirebaseGlob.ts.

Normally, the ServiceWorker will redirect navigation requests that don't match any `asset` or `data` group to the specified index file. Yet, sometimes it is desirable to configure the SW to ignore specific URLs (even for navigation requests) and pass them through to the server. This commit adds support for specifying an optional `ignoredUrlPatterns` list in `ngsw-config.json`, which contains URLs or simple globs (currently only recognizing `*` and `**`). Requests matching these URLs or patterns will not be handled by the SW. Fixes angular#20404

mary-poppins · 2018-04-12T11:30:06Z

You can preview 6239dfb at https://pr23025-6239dfb.ngbuilds.io/.

The ServiceWorker will redirect navigation requests that don't match any `asset` or `data` group to the specified index file. The rules for a request to be classified as a navigation request are as follows: 1. Its `mode` must be `navigation`. 2. It must accept a `text/html` response. 3. Its URL must match certain criteria (see below). By default, a navigation request can have any URL except for: 1. URLs containing `__`. 2. URLs to files (i.e. containing a file extension in the last path segment). While thse rules are fine in many cases, sometimes it is desirable to configure different rules for the URLs of navigation requests (e.g. ignore specific URLs and pass them through to the server). This commit adds support for specifying an optional `navigationUrls` list in `ngsw-config.json`, which contains URLs or simple globs (currently only recognizing `!`, `*` and `**`). Only requests whose URLs match any of the positive URLs/patterns and none of the negative ones (i.e. URLs/patterns starting with `!`) will be considered navigation requests (and handled accordingly by the SW). (This is an alternative implementation to angular#23025.) Fixes angular#20404

The ServiceWorker will redirect navigation requests that don't match any `asset` or `data` group to the specified index file. The rules for a request to be classified as a navigation request are as follows: 1. Its `mode` must be `navigation`. 2. It must accept a `text/html` response. 3. Its URL must match certain criteria (see below). By default, a navigation request can have any URL except for: 1. URLs containing `__`. 2. URLs to files (i.e. containing a file extension in the last path segment). While these rules are fine in many cases, sometimes it is desirable to configure different rules for the URLs of navigation requests (e.g. ignore specific URLs and pass them through to the server). This commit adds support for specifying an optional `navigationUrls` list in `ngsw-config.json`, which contains URLs or simple globs (currently only recognizing `!`, `*` and `**`). Only requests whose URLs match any of the positive URLs/patterns and none of the negative ones (i.e. URLs/patterns starting with `!`) will be considered navigation requests (and handled accordingly by the SW). (This is an alternative implementation to angular#23025.) Fixes angular#20404

gkalpak · 2018-04-12T22:03:02Z

Alternative implementation (supporting both positive and negative patterns) in #23339.

The ServiceWorker will redirect navigation requests that don't match any `asset` or `data` group to the specified index file. The rules for a request to be classified as a navigation request are as follows: 1. Its `mode` must be `navigation`. 2. It must accept a `text/html` response. 3. Its URL must match certain criteria (see below). By default, a navigation request can have any URL except for: 1. URLs containing `__`. 2. URLs to files (i.e. containing a file extension in the last path segment). While these rules are fine in many cases, sometimes it is desirable to configure different rules for the URLs of navigation requests (e.g. ignore specific URLs and pass them through to the server). This commit adds support for specifying an optional `navigationUrls` list in `ngsw-config.json`, which contains URLs or simple globs (currently only recognizing `!`, `*` and `**`). Only requests whose URLs match any of the positive URLs/patterns and none of the negative ones (i.e. URLs/patterns starting with `!`) will be considered navigation requests (and handled accordingly by the SW). (This is an alternative implementation to angular#23025.) Fixes angular#20404

…23339) The ServiceWorker will redirect navigation requests that don't match any `asset` or `data` group to the specified index file. The rules for a request to be classified as a navigation request are as follows: 1. Its `mode` must be `navigation`. 2. It must accept a `text/html` response. 3. Its URL must match certain criteria (see below). By default, a navigation request can have any URL except for: 1. URLs containing `__`. 2. URLs to files (i.e. containing a file extension in the last path segment). While these rules are fine in many cases, sometimes it is desirable to configure different rules for the URLs of navigation requests (e.g. ignore specific URLs and pass them through to the server). This commit adds support for specifying an optional `navigationUrls` list in `ngsw-config.json`, which contains URLs or simple globs (currently only recognizing `!`, `*` and `**`). Only requests whose URLs match any of the positive URLs/patterns and none of the negative ones (i.e. URLs/patterns starting with `!`) will be considered navigation requests (and handled accordingly by the SW). (This is an alternative implementation to #23025.) Fixes #20404 PR Close #23339

IgorMinar · 2018-04-13T21:41:18Z

superseded by #23339

angular-automatic-lock-bot · 2019-09-14T22:53:00Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

googlebot added the cla: yes label Mar 27, 2018

gkalpak requested a review from alxhub March 27, 2018 15:56

gkalpak added feature Issue that requests a new feature action: review The PR is still awaiting reviews from at least one requested reviewer target: major This PR is targeted for the next major release and removed cla: yes labels Mar 27, 2018

googlebot added cla: yes labels Mar 27, 2018

gkalpak added area: service-worker Issues related to the @angular/service-worker package and removed cla: yes labels Mar 27, 2018

googlebot added the cla: yes label Mar 27, 2018

alxhub approved these changes Mar 27, 2018

View reviewed changes

gkalpak mentioned this pull request Mar 27, 2018

Failed to load HTTP resource in live URL #23012

Closed

gkalpak force-pushed the feat-sw-ignore-urls branch 3 times, most recently from 557ccf0 to 9e6edca Compare March 28, 2018 15:19

gkalpak requested a review from IgorMinar March 28, 2018 15:20

gkalpak force-pushed the feat-sw-ignore-urls branch 2 times, most recently from b49b72d to 7f2155e Compare March 28, 2018 15:48

gkalpak mentioned this pull request Mar 30, 2018

Feature request: ngsw navigation path exceptions #20404

Closed

IgorMinar approved these changes Mar 30, 2018

View reviewed changes

gkalpak added 2 commits April 12, 2018 14:17

fixup! feat(service-worker): add support for ignoring specific URLs

6239dfb

gkalpak force-pushed the feat-sw-ignore-urls branch from 7f2155e to 6239dfb Compare April 12, 2018 11:18

gkalpak mentioned this pull request Apr 12, 2018

feat(service-worker): add support for configuring navigations URLs #23339

Closed

3 tasks

IgorMinar closed this Apr 13, 2018

gkalpak deleted the feat-sw-ignore-urls branch April 15, 2018 11:58

gkalpak mentioned this pull request May 5, 2018

feat(service-worker): Support ignoring specific URLs (e.g. for AJAX progress listener, video streaming, range requests, Firebase uploads) #21191

Closed

gkalpak mentioned this pull request May 13, 2019

feat(service-worker): Support ignoring specific URLs #30195

Closed

angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 14, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(service-worker): add support for ignoring specific URLs #23025

feat(service-worker): add support for ignoring specific URLs #23025

gkalpak commented Mar 27, 2018 •

edited

mary-poppins commented Mar 27, 2018

gkalpak commented Mar 27, 2018 •

edited

alxhub commented Mar 27, 2018

gkalpak commented Mar 27, 2018 •

edited

mary-poppins commented Mar 28, 2018

gkalpak commented Mar 28, 2018

mary-poppins commented Mar 28, 2018

gkalpak commented Mar 30, 2018

gkalpak commented Mar 30, 2018

IgorMinar left a comment

gkalpak commented Apr 5, 2018

mary-poppins commented Apr 12, 2018

gkalpak commented Apr 12, 2018

IgorMinar commented Apr 13, 2018

angular-automatic-lock-bot bot commented Sep 14, 2019

feat(service-worker): add support for ignoring specific URLs #23025

feat(service-worker): add support for ignoring specific URLs #23025

Conversation

gkalpak commented Mar 27, 2018 • edited

PR Checklist

PR Type

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

Other information

mary-poppins commented Mar 27, 2018

gkalpak commented Mar 27, 2018 • edited

alxhub commented Mar 27, 2018

gkalpak commented Mar 27, 2018 • edited

mary-poppins commented Mar 28, 2018

gkalpak commented Mar 28, 2018

mary-poppins commented Mar 28, 2018

gkalpak commented Mar 30, 2018

gkalpak commented Mar 30, 2018

IgorMinar left a comment

Choose a reason for hiding this comment

gkalpak commented Apr 5, 2018

mary-poppins commented Apr 12, 2018

gkalpak commented Apr 12, 2018

IgorMinar commented Apr 13, 2018

angular-automatic-lock-bot bot commented Sep 14, 2019

gkalpak commented Mar 27, 2018 •

edited

gkalpak commented Mar 27, 2018 •

edited

gkalpak commented Mar 27, 2018 •

edited