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

[1.3] webapp appears to force-serve manifest.json #6674

Closed
Primigenus opened this Issue Apr 1, 2016 · 29 comments

Comments

Projects
None yet
10 participants
@Primigenus
Contributor

Primigenus commented Apr 1, 2016

Since 1.3 it seems like apps are serving a /manifest.json file which appears to contain a long list of whether to cache specific resources. I imagine this might be used by something like mobile support to manage whether it needs to update things during hot code reload?

The line causing this behaviour appears to originate here: 2ccb746#L514

Steps to repro:

  1. create a new Meteor app using 1.3 and navigate to http://localhost:3000/manifest.json.

This breaks existing apps that were relying on their own manifest.json hosted in eg. /public being available, for instance in the case of wanting to provide a web app manifest according to the W3C Working Draft using <link rel="manifest" href="/manifest.json">.

Primigenus added a commit to Q42/q42.nl that referenced this issue Apr 1, 2016

@mitar

This comment has been minimized.

Collaborator

mitar commented Apr 1, 2016

Huh, yes, but that was fix of the omission in the past. The code was meant to server it, but it was not serving it.

There is a TODO to rename it to program.json. Maybe this could be a fix? To rename Meteor manifest to program.json?

@Primigenus

This comment has been minimized.

Contributor

Primigenus commented Apr 1, 2016

Yes, or consider naming internal Meteor files like this something that will less likely conflict with the app's files. Maybe serve from a /__meteor__/ folder or something?

@martijnwalraven

This comment has been minimized.

Contributor

martijnwalraven commented Apr 2, 2016

I wasn't aware this behavior was new in Meteor 1.3. Mobile support only needs /__cordova/manifest.json, but I always assumed it would also serve this for the main architecture (although it isn't used anywhere as far as I know).

Not sure how 53205bf and https://github.com/meteor/meteor/pull/6101/files change this.

@mitar

This comment has been minimized.

Collaborator

mitar commented Apr 2, 2016

No, this was the fix: #5713

@AndreasGalster

This comment has been minimized.

AndreasGalster commented Jun 28, 2016

Will this be fixed or is there another way how we can serve our manifest.json in the meantime?

@geremora

This comment has been minimized.

geremora commented Jun 28, 2016

I need serve my own manifest.json, but in meteor 1.3.4.1 still appears to contain a long list of whether to cache specific resources.

@abernix

This comment has been minimized.

Member

abernix commented Jun 29, 2016

The TODO (well, XXX) is still there in the code to rename this to program.json, but even that could lead to people asking the same question as above for program.json (e.g. "How do I serve a program.json since Meteor already serves one?!"). I guess manifest.json might be a more commonly clashing name though.

@AndreasGalster @geremora What kind of manifest is this that you are trying to serve? Is it not configurable to something else?

@abernix

This comment has been minimized.

Member

abernix commented Jun 29, 2016

Also, I don't think this is "mobile" related as far as Meteor is concerned at this point so removing that label as it's happening in the webapp code.

@AndreasGalster

This comment has been minimized.

AndreasGalster commented Jun 29, 2016

I'm trying to define a manifest.json with a gcm_sender_id for push messaging, which currently is not possible.

@mitar

This comment has been minimized.

Collaborator

mitar commented Jun 29, 2016

There is a standard to use .well-known path for such things: https://tools.ietf.org/html/rfc5785

I would suggest manifest is moved to .well-known/meteor/manifest.json.

Meteor should also register it: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

@abernix

This comment has been minimized.

Member

abernix commented Jun 29, 2016

@AndreasGalster You don't have to have the file named manifest.json – you can specify whatever you want according to Google's developer docs:

<link rel="manifest" href="some_other_manifest.json">
@lvnr

This comment has been minimized.

lvnr commented Aug 5, 2016

@abernix is correct @AndreasGalster, you can name it whatever you want, but you need to make sure that it's the first manifest included in the page if there are others.

@fmilani

This comment has been minimized.

fmilani commented Dec 5, 2016

@abernix I've renamed my manifest.json but I still can't make it work on chrome mobile (it doesn't appear as a standalone app), and I'm failing to find anyone with the same problem on the web.

Has anyone ever succeeded in creating their own manifest with meteor? I'm trying to make a progressive web app, with a splashscreen and no url bar...

I appreciate any help, thanks.

@mitar

This comment has been minimized.

@fmilani

This comment has been minimized.

fmilani commented Dec 5, 2016

@mitar That did changed the status bar color of my phone (I guess because of the meta tag theme-color). But still it is not in standalone mode and still no splashscreen shown, do you get these in your web app?

@mitar

This comment has been minimized.

Collaborator

mitar commented Dec 5, 2016

I haven't tested that. :-)

@fmilani

This comment has been minimized.

fmilani commented Dec 6, 2016

If someone else could tell if they got it working... I really don't know what I'm doing wrong. =(

@Primigenus

This comment has been minimized.

Contributor

Primigenus commented Dec 6, 2016

@fmilani You have to add it to your homescreen in order to trigger the splash screen and fullscreen options.

@fmilani

This comment has been minimized.

fmilani commented Dec 6, 2016

@Primigenus I did add it to my homescreen. Still no splashscreen or standalone

@hwillson

This comment has been minimized.

Member

hwillson commented Nov 22, 2017

Marking this as pull-requests-encouraged - if anyone is interested in jumping on this, please use the following (Meteor team approved) format:

/__meteor__/webapp/manifest.json
@mitar

This comment has been minimized.

Collaborator

mitar commented Nov 22, 2017

So we do not want to use standard .well-known?

@hwillson

This comment has been minimized.

Member

hwillson commented Nov 22, 2017

The idea was discussed, but there is precedent for using a pattern like the one suggested within the Meteor codebase (e.g. the bundle-visualizer is using something similar). The plan is to eventually standardize around the __meteor__/package-name pattern. Going through the process of being properly registered for a .well-known address isn't currently something that the team wants to spend time looking into (that may change in the future though!). Thanks!

@abernix

This comment has been minimized.

Member

abernix commented Nov 23, 2017

I took some more time to look into this this morning. I'm not sure that manifest.json is consumed by anything but Cordova, specifically in this portion of the cordova-plugin-meteor-webapp plugin (which Meteor Cordova apps use), and specifically at __cordova/manifest.json. Some of the tests of that plugin further elude to that theory, and I can't find any such code in the non-Cordova code.

I'm not sure if anyone can spot instances where we actually access manifest.json at the top level, but if we can hone in on whether or not that's necessary, the more preferable option here might be to just disable it. I'm not really keen on the idea of changing cordova-plugin-meteor-webapp to support this new URL.

@abernix

This comment has been minimized.

Member

abernix commented Nov 23, 2017

Regarding .well-known, I'm not sure even sure we meet the requirements for it. The RFC states, in section 1:

1.  Introduction

   It is increasingly common for Web-based protocols to require the
   discovery of policy or other information about a host ("site-wide
   metadata") before making a request.

And further clarifies in 1.1:

                                ...they are designed to facilitate
   discovery of information on a site when it isn't practical to use
   other mechanisms; for example, when discovering policy that needs to
   be evaluated before a resource is accessed, or when using multiple
   round-trips is judged detrimental to performance.

I don't believe we're accessing manifest.json before the request is made, but rather as subsequent requests when there are other practical mechanisms.

@hwillson

This comment has been minimized.

Member

hwillson commented Nov 23, 2017

I'm not sure that manifest.json is consumed by anything but Cordova

Interesting find @abernix - commit 05b2765 definitely points towards that being the case. It looks like the manifest.json was always (and only) served up via /cordova/manifest.json until that commit. I can't find any reason why it needs to be available at /manifest.json - it just looks like that commit was refactoring things a bit and decided to make the manifest serving code a little less architecture specific. So we can probably drop it? I'll give it a shot. Thanks!

@hwillson hwillson self-assigned this Nov 23, 2017

@mitar

This comment has been minimized.

Collaborator

mitar commented Nov 23, 2017

So we used manifest.json for multi-target Meteor fork. For web workers and service workers, then we made targets for them and then they had their own manifest a worker loaded to know which things it can import. We also fetch manifest first, before everything else, because there you do not have index.html to load, but you load resources directly. One good use of manifest for us was also that after we loaded manifest, service worker was able to check manifest against a signature, and then any resource it loaded, it checked against the manifest (and hash there). So we were able to detect compromised servers where server might start serving malicious code.

So I would say the question is if Meteor is planing to ever support multiple targets. Or have a service worker to dynamically load code. I think allowing custom targets would be great, and would allow things beyond just Cordova and workers, but maybe even Electron and so on. So the question is: is Cordova the only one using it because it is the first use of it, or it is t he last one?

Oh, one more use case is also in Assets package. If one wants to be able to be able to list available assets and resolve them to client-side URIs. Then manifest seems to be the best way to do so. There is no code for it yet though. But this is one of my pain points with assets for a long time.

And so that commit changed manifest with anticipation of going with more targets. I made other additional pull requests which at the time looked like they will go in.

@abernix

This comment has been minimized.

Member

abernix commented Nov 24, 2017

@mitar Even with that explanation/use case, I see no reason that any such manifest.json file would need to be served top level.
Correct?

@Primigenus

This comment has been minimized.

Contributor

Primigenus commented Nov 27, 2017

Just a quick note that these days, the recommended file to serve is manifest.webmanifest, with a mimetype of application/manifest+json. So perhaps we can avoid the collision completely by referring people trying to serve manifest.json to the documentation: https://developer.mozilla.org/en-US/docs/Web/Manifest

@hwillson

This comment has been minimized.

Member

hwillson commented Nov 27, 2017

Thanks @Primigenus - the name is still optional though, and many people (like Google) are still recommending (by example) manifest.json. I think at the very least we should still consider getting Meteor's manifest.json out of the top level.

hwillson added a commit to hwillson/meteor that referenced this issue Nov 28, 2017

Stop serving the application manifest from /manifest.json
Meteor currently serves its own manifest file from
`/manifest.json`. This location is not application
configurable, and can conflict with other non-Meteor
defined manifest files, that are already being served
from this location. There isn't really any reason why
Meteor needs to use the `/manifest.json` location, so
this commit moves it to `/__meteor__/webapp/manifest.json`.

Fixes meteor#6674.

@benjamn benjamn closed this in #9424 Dec 1, 2017

benjamn added a commit that referenced this issue Dec 1, 2017

Stop serving the application manifest from /manifest.json (#9424)
* Stop serving the application manifest from /manifest.json

Meteor currently serves its own manifest file from
`/manifest.json`. This location is not application
configurable, and can conflict with other non-Meteor
defined manifest files, that are already being served
from this location. There isn't really any reason why
Meteor needs to use the `/manifest.json` location, so
this commit moves it to `/__meteor__/webapp/manifest.json`.

Fixes #6674.

* Add PR link to History.md
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment