Closed jakearchibald closed 4 years ago
Appreciate the feedback. Here are my thoughts below.
It is a key scenario for our internal customers that a single PWA is able to handle links from outside its app scope, including those that are from a different domain. A simple example of why this is necessary is shortened links: "contoso.microsoft.com/some/resource/12345" and "contoso.ms/ghg4lkgjh" may refer to the same resource.
Note that the subject of vanity URLs also pertains to w3c/ServiceWorker#1457.
service-worker-scope-pattern-matching looks interesting but as written would only be useful for declaring a PWA's own scope, not external "scopes". However, if the pattern matching format is superior, I have no qualms about using it here to declare "external scopes" for a specific purpose (url handling in this case).
The intent is for the URLPattern
part of the explainer to be consumable by other parts of the web platform. So if we had something called "external scopes" then it could be passed there. Anyway, its something I'm working on and the explainer is a bit out-of-date to my current thinking. Happy to sync on more details if you have questions/interest.
I mentioned the requirement for cross-origin url matching as one reason why we need the format to be declarative in the web app manifest. There is another reason: once this effort gets underway, we would like to work on registering the url handling registrations with OSes. This would help PWAs behave more like native applications.
@wanderview
I read the URLPattern
explainer again much more closely. I especially appreciated the discussion about matching performance.
Correct me if I'm wrong, but I believe that explainer does not allow for sub-domain wildcard in the baseUrl
. This would be a problem for us because we have a requirement that, for example, "organization1.contoso.com" and "organization2.contoso.com" can both be handled by the same PWA. That PWA would need to have to filter for "*.contoso.com" + paths.
It seems difficult to match a wildcard prefix with predictable performance if the base
or baseUrl
is allow to contain additional path segment beyond the origin/host. If the base
is instead limited to being a origin/host, we could match it in reverse. Alternatively we could match the input url against a map of registered host
s by removing one sub-domain as a time.
I think we can support wildcards in the host. If you used a pattern like that for service workers then the service worker API would reject. Basically we would compile the pattern to an internal representation with things like "has wildcard in host", etc and then the other APIs would check that.
The syntax is not finalized, but for hosts I was expecting to do something more like this:
new URLPattern({
baseUrl: location.self,
host: '*.example.com',
path: '/foo/*',
});
The host
and path
parts would override the info in baseURL
. So scheme, port, etc would come from baseURL
in this case, but host
and path
override those parts. This example pattern would not be usable with service workers, but your API could possibly accept it.
But in short, if you have requirements lets talk.
Hi, I have some additional feedback. As one of the authors of the WICG/sw-launch explainer, I think there's a lot of overlap here with sw-launch so I'm interested in either combining the two proposals, or teasing them apart so that they provide mutually exclusive functionality. I see you're already planning an update to the explainer that takes sw-launch into account.
Further feedback:
scope
is too inflexible (e.g., need to be able to exclude sub-paths), then we should work on expanding the scope syntax, which @wanderview is doing here. We shouldn't design a more flexible version of scope, but have it apply only to link capturing./.well-known/pwa-site-association
is baked into the spec is a bit restrictive. (I know native app digital links schemes do this.)
/favicon.ico
, for extremely old historical reasons, and that is considered a mistake.pwa-site-association
: We've never (to my knowledge) formally used the term "PWA" in a spec; it has been thought of as a marketing term. I doubt we should call it this.Just a data point on one item here:
I do feel like the out-of-scope URL thing is a bit unusual here. If you want a "vanity URL", can't you just redirect and then have the redirection cause a link capture? (For example, https://conto.so/foo could redirect to https://contoso.com/foo which would then open in a new app window.)
This kind of redirect is quite heavyweight if the PWA wants to support offline for the vanity URL. You need a service worker installed on both origins. In browsers that do site isolation you then end up creating a process just to run the vanity URL SW that redirects to the real origin. Finally you create a second process to run the real origin SW and page. See w3c/ServiceWorker#1457 for more discussion.
The fact that the special path /.well-known/pwa-site-association is baked into the spec is a bit restrictive. (I know native app digital links schemes do this.)
I have also wondered if this proposal should lean on origin policy instead of creating another well-known URL location.
But it also makes me kind of worried about the issues that have arisen for origin policy. Mainly, trying to support the following simultaneously:
Origin policy has run into difficulties here, though, because it wants to consult policies for cross-origin subresource loads. Maybe its not as difficult for only navigations like this use case is targeted at.
I think there is some discussion of updating in the explainer, but it would be nice if it explicitly covered how offline use cases would be satisfied.
Closing here. I will split up this thread into individual issues at https://github.com/WICG/pwa-url-handler/issues.
This is just my personal feedback, I haven't coordinated with others.
URI vs URL
From https://url.spec.whatwg.org/#url-apis-elsewhere
Patterns vs code
The explainer proposes a new pattern matching format. I think this comes with a lot of risk. We don't want a situation where another spec needs a pattern, but the one here doesn't quite fit, so they create yet another format etc etc.
@wanderview is looking into a more general URL pattern matcher: https://github.com/wanderview/service-worker-scope-pattern-matching/blob/master/explainer.md.
However, does this need to be declarative? In service worker land, we generally prefer code to config, and only use config if we have a good reason why code won't work. Eg, something like a "launch" event could work here.
Cross origin
Can you go into more detail on why the cross-origin stuff is important? It seems pretty risky, and again we'd want to avoid a situation where we end up creating lots of things that do almost do the same thing.