Turns out AppCache on Safari 7 is totally broken (see
http://stackoverflow.com/questions/22888945/safari-7-application-cache-does-not-work).
This, combined with our "reload if you can't load CSS or JS" strategy for
multi-server deploy causes infinite reloads in some cases.
Hopefully this will resolve the sporadic complaints we get
from some users about infinite reloads.
Previously, you could leave out the "support" field (or claim to not
support the version you were proposing) which would mean your connection
would succeed iff the proposed version is the server's favorite
version. This led to (eg) ObjectiveDDP accidentally writing a client
that stopped working when servers started preferring pre2 over pre1. By
making this a blatant error, DDP client libraries are more likely to
be written in a way that works with version negotiation.
Also, remove the delay in sending connect failure messages, which was
intended to avoid connect storms from clients that are by now 1.5 years
old.
Fixes#2125.
They are not safe for spaces in paths. There might be other places to look for trouble.
I've run the following command to produce this commit: (on OS X, copy-and-pasting the below exactly)
find . -type f -name '*.sh' -print0 | # Find all .sh files
xargs -0 fgrep -H -- '`' | # See all places with backticks in them
fgrep 'cd `dirname $0' | # I deemed these problematic (variable assignments are safe)
cut -d ':' -f 1 | # Take the <file> from <file>:<line> produced by "grep -H"
tr '\n' '\0' | # Also here, spaces can be problematic - always do "xargs -0"!
xargs -0 -- sed -i '' 's/cd `dirname $0`/cd "`dirname "$0"`"/g'
The significance of adding the two levels of "'s can be verified by running the following in your Terminal:
$ node -e 'console.log(process.argv.splice(1))' -- `echo 1 2`
[ '1', '2' ]
$ node -e 'console.log(process.argv.splice(1))' -- "`echo 1 2`"
[ '1 2' ]
$ node -e 'console.log(process.argv.splice(1))' -- "`echo "1 2"`"
[ '1 2' ]
It was flaky before because template rendered callbacks get called
after flush time, but not if the template got destroyed in the meanwhile.
The way this test was written, if the client managed to respond to the server
rejecting the method before the client's flush cycle, the rendered callback
would never fire. Thus it would hang, since that callback was wrapped
in an expect.
Now we define a method on the client only, which makes it run as a stub
without the server rejecting the method (ever).
Follow-up to 63b3119; further addresses #2095.
There were a few problems here:
- We didn't check that the argument to insert was a document. (EJSON
custom types don't count as documents, because they don't have _ids!)
- The check to see if something coming from the database was an EJSON
custom type didn't match the check in ejson.js (specifically, it was
missing size===2). This made it sort of look like you could use EJSON
custom types as top-level documents, until a change in the MongoDB
driver made made that coincidental almost-working code stop working.
- The replaceNames function wasn't documented as only taking pure JSON,
so it wasn't obvious that "it throws when there's a Buffer" was a bug
in the caller rather than a bug in replaceNames.
This should all be resolved now. Use cases like CollectionFS which were
mislead by these bugs into believing that an EJSON custom type could be
a document should move their custom type into a field.
The large number of conflicts is because release-0.8.1.1 was branched
off of release/0.8.1 instead of master.
Conflicts:
History.md
docs/.meteor/release
docs/lib/release-override.js
examples/clock/.meteor/release
examples/leaderboard/.meteor/release
examples/parties/.meteor/release
examples/todos/.meteor/release
examples/wordplay/.meteor/release
scripts/admin/banner.txt
scripts/admin/notices.json
mongodb 1.4.0-rc9 has a `binId` field of type Buffer on ObjectIDs, which
caused Meteor to crash when retrieving a document that was made up of
just an EJSON user-defined type. (Which should not necessarily be
supported, but `replaceNames` should probably treat Buffers as Arrays
regardless.)
Fixes#2095.
This was a regression in 0.8.1 which caused client-specified `_id` to
always be ignored for collections with at least one allow/deny rule.
Fixes#2097. Fixes#2099.
This was a regression in 0.8.1 which caused client-specified `_id` to
always be ignored for collections with at least one allow/deny rule.
Fixes#2097. Fixes#2099.
