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.
In many production systems logs from the application will be forwarded to various logging systems, sometimes third party ones. All credentials in your settings will be leaked if you have any errors in your json.
Feature request can be found here
https://github.com/meteor/meteor-feature-requests/issues/293.
The internal `client.s` property is no longer necessary to create the database object. If `MongoClient.prototype.db` is called without arguments, it will use the database name from the connection URI
(https://jira.mongodb.org/projects/NODE/issues/NODE-1258).
Fixes#9827.
The client.s.databaseName property appears to have been introduced a long
time ago (in 2014), so it seems reliable:
14fd60b99d
The use of client.s.options.dbName was only recently introduced in #9790,
since the MongoDB.connect callback now receives a MongoClient object
rather than a Db object. Not sure if client.s.options.dbName was ever
reliable, but at least we know when the problem started.
Workaround for #8598: the Node Mongo driver has at least one bug that can lead
to query callbacks never getting called (even with an error) when leadership
failover occur.
Note that while we did fix one Node Mongo driver bug and close#8598, we've
heard reports that there are more similar issues, so this workaround seems like
a good plan.
* Update MongoDB driver to 3.0.5
* Use `MongoClient` instead of `Db` in Meteor Tool
* Update `mongo-livedata` test for new MongoDB driver version
* Consider `BulkWriteError` when checking MongoDB errors
Since jquery used to be a core package, and the most recent Meteor release
(1.6.1.1) imposed the ~1.11.11 constraint (note the ~), jquery@1.12.1
won't be usable with Meteor 1.6.x until it is republished after the next
Meteor release, which will no longer constrain the jquery version, because
jquery is no longer a core package (#9607).
In order to publish these two packages sooner rather than later, we need
to relax their jquery version constraints, because we don't want to
publish jquery@1.12.1 yet. The relaxed @1.11.11 constraints in these
package.js files will remain compatible with jquery@1.12.1, so this change
should be safe for the forseeable future.
