Location of pwa-site-association file

[LuHuangMSFT]

Should the location of where a pwa-site-association file can be found not be specified and be left up to the UA as implementation detail?

[LuHuangMSFT]

Original comment from MicrosoftEdge/MSEdgeExplainers#300:

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.)
It's fairly unusual for a web spec to visit a hard-coded path relative to the root of an origin. As far as I know, the only other place that happens on the whole web platform is /favicon.ico, for extremely old historical reasons, and that is considered a mistake.
The name 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.

[wanderview]

I think I had a related comment about this that you could consider using origin policy instead of a separate well-known location file.

[LuHuangMSFT]

Modified explainer such that file location and other aspects of validation will not be specified but will be left to implementers.

[mkruisselbrink]

It seems that file location and how validation works if the most important part of this spec, so I don't understand how that can be left to implementers if you want to have any hope for interoperable implementations.

I don't understand what the concerns were around some file in /.well-known/ either, afaik that is a well established mechanism, used by several existing web standards (including origin policy).

Integration with origin policy might be interesting as well, although I'm not sure how exactly that would look/how much sense that would make.

[LuHuangMSFT]

It has been a while since I looked into this. I will revisit this issue soon and do a more thorough evaluation.

Current options:

• .well-known IETF RFC 5785
  • the sub-domain wildcard scenario is a problem here since .well-known is for the "discovery of information
    about an origin [RFC6454] (sometimes called "site-wide metadata")", not information about other origins (sub-domains are technically different origins)
  • requires registration to avoid collisions
• origin-policy
• something similar to how the manifest is discovered via. <link rel="manifest" ... > in the document.

[mkruisselbrink]

I'm not sure how the link rel approach would work? Doesn't that just move the problem from "what url to load the pwa-site-association file from" to "what url to load a document from"? It adds a layer of indirection, but still relies on some way of mapping an origin to a url (the url just happens to be a document instead of the final mapping file in that case).

[LuHuangMSFT]

Apologies. I must have missed the above reply.

If we want to fetch some metadata from the origin of a URL. I don't think we can avoid doing that mapping. .well-known maps using a static path after the site. origin-policy uses .well-known and further maps to origin. the link rel approach would assume that there is a document at the origin URL, fetch that and go from there. (I don't think that's a good assumption.)

origin-policy is more established and we wouldn't have to register another name within .well-known. It also has the benefit of already targeting origins, unlikely .well-known which targets the entire site. Placing a .well-known directory at the root of the origin (as I had originally imagined) isn't something that exists in the RFC. Origin owners may not have access to .well-known at the root.

I'm starting to think origin-policy is the best option out of what I've considered for interoperability.

[anormal81]

The explainer states the following suggestion:

Alternatively, we suggest browsers locate it using a <link rel="web-app-origin-association" href="/web-app-origin-association"> element in the header section of the main document at the origin's root path.

We would explicitly welcome this location, since our software is also deployed in application servers like JBoss and Tomcat. There we can't register the .well-known URL in the root, because it is not defined if other applications of the same server have to put something there as well.

Furthermore, our software provides several PWAs under different sub contexts. Some of these contexts can be installed as PWAs. The HTML documents of these sub contexts deliver the PWA manifest via an href in a link tag.

For these two scenarios, we strongly advocate web-app-origin-association support for various sub contexts without /.well-known.