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
This partially reverts commit 99b79dc00f,
which was added as part of PR #10055 in an effort to trigger hot reloads
on the client when/if the definition of a "modern" browser happened to
change, due to server code calling setMinimumBrowserVersions. Although
changes in the minimum modern browser versions are pretty rare, it seemed
important to incorporate this information into the client hash, because
code sent to the client tends to be dramatically different depending on
whether the client is considered modern.
However, this change was made without updating the corresponding version
calculations in CordovaBuilder#appendVersion in tools/cordova/builder.js,
so the versions in program.json for Cordova apps disagreed with the
versions served in manifest.json by the web server, leading to the
problems described by @lorensr in this cordova-plugin-meteor-webapp issue:
https://github.com/meteor/cordova-plugin-meteor-webapp/issues/69
It would be nice to include the minimum versions hash in program.json for
Cordova builds, but unfortunately these versions are not known at build
time, because they are determined by calls to setMinimumBrowserVersions
during server startup. In other words, if we wanted to access that
information during Cordova builds, we would have to start the web server
and run all server-side application initialization code just to find out
if setMinimumBrowserVersions was called anywhere.
In the future, we could consider including the minimum versions hash in
manifest.json, so cordova-plugin-meteor-webapp could compare the current
version to the new version whenever it fetches manifest.json. However, I
think simply removing the minimum versions hash from the client version
calculation is a fine solution in the meantime. If a developer needs to
trigger a hot reload because they changed their minimum modern versions,
they should just be sure to change their client code at the same time.
Any change that would normally trigger a client reload will work.
When generating boilerplate, meteor runtime config includes additional
options based on the arch.
However, these additional options were not present when generating
the response to `/meteor_runtime_config.js`, which is used when
inline scripts are disabled.
This change fixes Meteor.isModern in those circumstances.
The inline middleware that strips the ROOT_URL_PATH_PREFIX destroys req.url. If this happens before the query parameters are parsed by use(query()) the query parameters are always missing. This causes OAuth authentication to fail when ROOT_URL_PATH_PREFIX is set.
A better fix would be to fix the path stripping logic so that it preserves the URL parameters, since other things may try to rely on them later. But this works for now.
It seems obvious in hindsight, but any logic relating to the
AUTOUPDATE_VERSION override should reside within the autoupdate package,
and the true client hashes should be available to any other package that
needs them, without AUTOUPDATE_VERSION getting in the way.
Fixes#10073, per
https://github.com/meteor/meteor/issues/10073#issuecomment-405290391
While thinking about this bug, I realized that sending IPC messages to
specific packages in the server process was much less flexible than
sending messages based on an arbitrary topic string, since the topic
string approach allows both `autoupdate` and `dynamic-import` to listen
for the same message.
The topic string approach calls for a listener interface like
`onMessage(topic, callback)`, which elegantly replaces the previous
approach of requiring packages to export a single `onMessage` function.
However, because the `meteor` package does not have access to the module
system, implementing the `onMessage` listener interface in the `meteor`
package would have required exposing an API like `Meteor.onMessage(topic,
callback)`, which has an unpleasant global smell to it. Instead, the
`onMessage` function should be explicitly imported (using the module
system) from a less-generically-named package.
Since I knew I was going to have to move the message dispatch logic out of
the `meteor` package, I decided to create a new package called
`inter-process-messaging` to implement the parent/child components of the
IPC system.
Instead of having every message consumer listen to every message and act
on the ones that seem relevant to its interests, we now have a single
process.on("message", callback) hook that can dispatch messages to
different Meteor packages running in the server process.
Receiving packages should export an onMessage function. The onMessage
function may be async, and its result will be delivered back to the build
process as the result of the sendMessage Promise.
Now that we're postponing the legacy build until after the first client
refresh message is sent, there's a risk that changes to the legacy build
will not be picked up until after the next rebuild.
If we attempted to fix that problem by sending the refresh message after
the legacy bundle is rebuilt, then we would lose most of the benefit of
delaying the legacy build, because the client would not refresh until
after the legacy build completed.
The right way to fix the problem is by sending a second client refresh
message after the legacy build finishes, but doing so with the current
autoupdate implementation would very likely cause modern clients to reload
a second time.
The solution implemented by this commit is simple in theory: the
autoupdate package should keep track of distinct versions for each client
architecture, so that modern clients will refresh only when the modern
versions change, and legacy clients will refresh only when the legacy
versions change, which allows us to send two refresh messages without
causing any clients to refresh more than once.
In reality, this was a fairly major rewrite, since the ClientVersions
collection has a totally different schema now. I've tested it as well as I
can, though I'm not entirely sure what will happen if clients using the
previous version of the autoupdate package begin receiving DDP messages
from this version of the autoupdate server code.
This means the autoupdate package is no longer responsible for recomputing
client hashes, and we can recompute the hashes whenever there's a new (or
updated) client program, which enables delayed builds of architectures
like web.browser.legacy (#10055).
The only new functionality is the res.setHeader("Vary", "User-Agent")
call; the rest of the changes in this commit are just reformatting.
@CaptainN I think this should be enough information for well-behaved
browsers and CDNs to do the right thing, though I agree it's worth
documenting.
Since legacy assets are no longer disambiguated from modern assets with a
/__browser.legacy/ URL prefix (#9776), we need a principled way to handle
collisions in the staticFiles registry.
PR #9343 changed the return type of Boilerplate#toHTML from String to
Stream, which is likely to break existing code that expects a string.
In order to make the change in return type more obvious, I have renamed
the method to toHTMLStream, and I have attempted to update all call sites
appropriately. However, because this change comes in the release candidate
phase of Meteor 1.6.1 testing, it seemed important to preserve the
string-returning behavior of toHTML, with a deprecation notice.
Unless third-party code is using the Boilerplate class directly, I don't
think the toHTML method will ever be called, and we can remove it in
Meteor 1.6.2.
Thanks to @macrozone for tracking this problem down.
Fixes#9521.
* 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
