The forEach method on Hook will stop iterating unless the iterator
function returns a truthy value. Previously, this meant that only the
first registered runtime config hook would be called.
There are replaceable files when the app was built with the --debug option, and then run with NODE_ENV set to production. There are no problems with replaceable files.
- To know which change sets to apply, the client needs to know when the version running was built. It used the time the client loaded, but it could have loaded after a new version of the app was built, especially on cordova. Now it uses the actual time the client was built.
- On cordova, there is a delay between the client knowing there is an update available, and being able to reload the page to use the new version.
This is useful because the worker id, which is used by default to name the UNIX socket file, is incremented each time the worker process ends/dies. This will cause difficulties if you are referencing the UNIX socket file from a web server or other external process where you expect the socket file to always have the same name.
Co-authored-by: Rokas Stankevicius <rokanost@users.noreply.github.com>
Fix incorrect responses, like sending content to OPTIONS requests, by implementing the following scheme:
GET
- Respond with the requested resource; static asset, boilerplate etc.
HEAD
- Return headers identical to GET request
- Do not send content (Node.js will automatically skip response content)
OPTIONS
- Respond with 200
- Send an Allow Header listing acceptable request methods
- Do not send content
CONNECT, DELETE, PATCH, POST, PUT, TRACE, etc.
- Respond with 405 Method Not Allowed
- Send an Allow Header listing acceptable request methods
- Do not send content
Follow-up to #10824.
If the preferred arch is not available (most likely because it was
deliberately excluded), it's better to use another client arch that is
available than to guarantee the site won't work by returning an unknown
arch. For example, if web.browser.legacy is excluded using the
--exclude-archs option (introduced by #10824), legacy clients are better
served by receiving web.browser (which might actually work) than receiving
an HTTP 404 response. If none of the arches in preferredArchOrder are
defined, only then should we send a 404.
Revert "Bump webapp version to 1.8.2, with same content as 1.8.0."
This reverts commit 20d2a9b4a4.
Revert "Revert changes to webapp package since version 1.8.0."
This reverts commit 7a6ee9e129.
We accidentally published changes to webapp that should have been
restricted to Meteor 1.10 as part of the 1.8.1 version. This commit
reverts commits to packages/webapp since Meteor 1.9, so that we can
republish the 1.8.0 content as version 1.8.2. We will then bump the webapp
version to 1.9.0 on the release-1.10 branch and publish the new content
only on that branch.
Revert "Allow to exclude web architectures in development mode (#10824)"
This reverts commit a205967186.
Revert "Updates cordova-plugin-meteor-webapp to 1.7.1"
This reverts commit a1e4d27822.
Revert "Update cordova-plugin-wkwebview-engine to 1.2.1."
This reverts commit 3f9a69d7c4.
Revert "Update cordova-plugin-whitelist to 1.3.4."
This reverts commit 979273333b.
Revert "Update cordova-plugin-meteor-webapp to 1.7.1-beta.1."
This reverts commit 565c4254f1.
Revert "Update accounts-password to version 1.5.2."
This reverts commit b827d1da2f.
Although Meteor doesn't send cache headers to the runtime config file, a reverse proxy might still cache it.
Some reverse proxies will treat this case similar to cache-control: private.
So adding the hash can prevent reverse proxies from serving stale versions.
Furthermore, by adding the hash, it can actually be cached correctly by reverse proxies.
For more context: https://github.com/meteor/meteor/issues/10733
