This reverts commit 5d3cfa2d76, reversing
changes made to 2b466a9015.
Ah well, we tried to enable websocket compression again and ran into
more bugs.
First, newer versions of websocket-driver seem to sometimes send
duplicate close messages:
https://github.com/faye/faye-websocket-node/issues/41
This occurs whether or not deflate is actually used.
Second, in some circumstances permessage-deflate seems to completely
corrupt messages. This was reasonably easily observable by running
test-packages with Chrome, and seeing that sometimes (but not always) a
large number of bad JSON messages got printed to the client
console. (Another symptom was that the total number of tests would be
larger than it should be, leading to messages like "Passed 1109 of
1153", presumably because the test name got corrupted in some status
messages.) https://github.com/faye/permessage-deflate-node/issues/4
See #3007.
This reverts commit 67bea9c102.
See https://github.com/faye/permessage-deflate-node/issues/1
This can be consistently replicated by running test-packages ddp (note
that the tests pass but then the server crashes). "livedata server -
connection in publish function" specifically is enough
By default, we attempt to use this for every websocket message on both
client and server.
On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md
We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
https://github.com/faye/permessage-deflate-node/issues/2
We do not provide a mechanism to control compression parameters on the
client side. The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)
Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
This should mean that you can access the package server from behind a
corporate firewall.
I tested this by setting up a Linux machine that doesn't have access to
packages.meteor.com:
$ sudo iptables -A OUTPUT -d 54.225.216.115 -j DROP
$ sudo iptables -A OUTPUT -d 184.72.252.20 -j DROP
$ sudo iptables -A OUTPUT -d 23.23.114.56 -j DROP
I confirmed that these commands both fail:
$ curl https://packages.meteor.com/
$ ./meteor search asdf # when it needs to sync first
I bought a proxy server from Proxy Bonanza and confirmed that setting
the environment variable HTTPS_PROXY to
https://PROXYUSERNAME:PROXYPASSWORD@PROXYIP:PROXYPORT/
made both of the commands above succeed.
Fixes#2515.
We want to support running DDP through a corporate proxy, but the
higher-level faye-websocket can't support that and won't be changed to
allow that: https://github.com/faye/faye-websocket-node/pull/30
Fair enough. Let's just switch to the lower-level module, since we don't
care about getting a browser-compatible websocket API.
This is a first step towards fixing #2515.
