Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify the location of the Web Application Manifest #24

Open
reillyeon opened this issue Oct 13, 2023 · 6 comments · Fixed by #34
Open

Specify the location of the Web Application Manifest #24

reillyeon opened this issue Oct 13, 2023 · 6 comments · Fixed by #34
Assignees

Comments

@reillyeon
Copy link
Collaborator

No description provided.

@mgiuca
Copy link
Member

mgiuca commented Jan 19, 2024

It seems that it's hard-coded to be at /manifest.webmanifest (which is the example name given in the Manifest spec).

Consider moving it to /.well-known/manifest.webmanifest. Per RFC 8615, to avoid "usurp[ing] the origin's control over its own URI space", resources that are mandated by a spec to live in a precise URL should be within the /.well-known/ directory.

In a private discussion with someone internally (anonymous since it was a private discussion), they said: "[Changing it] would make things more difficult for developers, especially during the transition period where Chrome and the packaging tools we made disagree about where it should go." I would suggest that while standards are still being prototyped and have not been released on any browser, we should be amenable to making design changes even if they disrupt developers. If necessary, Chrome could have a grace period where it looks at the new location and falls back to looking at the old location with a warning.

@scheib
Copy link
Collaborator

scheib commented Jan 19, 2024

Seems reasonable. .well-known, though proposed in 2019, has not progressed to best practice or standard yet. (Note, I'm not familiar with IETF context to understand why). MDN doesn't appear to have use of well-known, I didn't find W3C standards yet using it (difficult to search), though I did find a list at https://en.wikipedia.org/wiki/Well-known_URI

@reillyeon
Copy link
Collaborator Author

I think the only example I've seen of it in a proposed web standard is in First Party Sets. I'm not opposed to migrating.

@mgiuca
Copy link
Member

mgiuca commented Jan 22, 2024

Good point that .well-known may not be very prominent in standards yet.

The Wikipedia page suggests quite a few official IETF uses including http-opportunistic in HTTP/2. FWIW we have proposed using it for Scope Extensions in Manifest itself which is quite close to home.

@HughIsaacs2
Copy link

Seems reasonable. .well-known, though proposed in 2019, has not progressed to best practice or standard yet. (Note, I'm not familiar with IETF context to understand why). MDN doesn't appear to have use of well-known, I didn't find W3C standards yet using it (difficult to search), though I did find a list at https://en.wikipedia.org/wiki/Well-known_URI

Might be an issue with MDN search because it's definitely in this FedCM article.
https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API#provide_a_well-known_file

@robbiemc
Copy link
Collaborator

Oops, #34 does not fix this :)

@robbiemc robbiemc reopened this Apr 22, 2024
cyhuang1230 added a commit to GoogleChromeLabs/cros-sample-telemetry-extension that referenced this issue Sep 30, 2024
The location of IWA manifest was changed from `/manifest.webmanifest` to
`/.well-known/manifest.webmanifest` [1]. Reflect that change in our
sample IWA.

[1] More discussion: WICG/isolated-web-apps#24
cyhuang1230 added a commit to GoogleChromeLabs/cros-sample-telemetry-extension that referenced this issue Oct 3, 2024
* [Build] Move manifest to .well-known/

The location of IWA manifest was changed from `/manifest.webmanifest` to
`/.well-known/manifest.webmanifest` [1]. Reflect that change in our
sample IWA.

[1] More discussion: WICG/isolated-web-apps#24

* [Build] Sign IWA with Integrity Block V2

Integrity Block V1 has been deprecated since M129. Upgrade npm package
`wbn-sign` to 0.2.1 to support v2 format.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants