-Access-Control-Max-Age header only has meaning for preflights, not
POST or GET, saves wire bytes by excluding it from POST/GET/etc,
and future problems if ACMA on a content HTTP method is given
meaning by W3C or a browser vendor
-fix expectNoHeader() test helper func ,this was a no-op before by
accident and would NEVER fail,
supertest/test.js:Test.prototype._assertFunction requires an retval of
class type Error if test fail, not a string or a number or Object
The test broke because Node lowered the maximum header size to defend
against large headers ( CVE-2018-12121 ).
In the test, we do actually want to pass large headers, because all
processing in CORS Anywhere is based on headers (the request body would
just be forwarded to the destination server).
The test failed intermittently with ECONNRESET or "socket hang up"
because the server (under test) would close the socket upon receiving
a request with too large request headers.
Starting from Node 12, the test started to fail because of
intermittent socket errors, such as ECONNRESET and "socket hang up".
Destroying the response before triggering a new request resolves it.
Travis build failed on "Uncaught TypeError: Object.keys called on non-object".
That's a real error (res._headers was initially null until a header is set).
- Add checkRateLimit option to the API.
- Extend the default server.js with environment variables
CORSANYWHERE_WHITELIST (re-using originWhitelist) and
CORSANYWHERE_RATELIMIT (using the new checkRateLimit option)
to make it easy to enforce usage limits.
- Document that Heroku doesn't want open proxies.
Some clients try to use CORS Anywhere, even for same-origin requests...
Add a new setting "redirectSameOrigin" to not waste server resources on
proxying such requests.
Fixes#42
Node.js has forbidden header names with spaces in
6192c9892f.
The next error is thrown when the test sets the "some header" header:
Uncaught TypeError: Header name must be a valid HTTP Token ["some header"]
To fix it, replace spaces with dashes.
Using the performNRequests, I collected the following statistics
before choosing the maximum allowed "leaked" memory.
Node.js 0.12.2,
Using the http module ('use-http-instead-of-cors-anywhere'):
Memory usage delta: 132800 (100 requests of 50 kb each, 250ms)
Memory usage delta: 110144 (100 requests of 1 kb each, 172ms)
Memory usage delta: 709936 (1000 requests of 1 kb each, 902ms)
Memory usage delta: 865104 (10000 requests of 1 kb each, 7073ms)
Memory usage delta: 930416 (100000 requests of 1 kb each, 62856ms)
Using CORS Anywhere:
Memory usage delta: 356784 (100 requests of 50 kb each, 1004ms)
Memory usage delta: 355248 (100 requests of 1 kb each, 641ms)
Memory usage delta: 1326856 (1000 requests of 1 kb each, 3338ms)
Memory usage delta: 1462584 (10000 requests of 1 kb each, 21186ms)
Memory usage delta: 1473624 (100000 requests of 1 kb each, 211202ms)
Clearly, there is a small leak, but it is not proportional/linear
in terms of the number of requests, so the observed "leak" is probably
not an issue. Furthermore, the "leak" also occurs with the plain
http module.
After setting fixed limits, I ran the tests on Node.js 0.10.25 and
observed that the tests failed due to the too low limits, so I
incremented the limits (400 -> 550, 1500 -> 2000).
All xfwd and tests fails with this change, but that's because the
tests themselves were incorrect (using port 80/443 instead of the
ephemeral ports created for the tests).
webkit-devtools-agent (tested with 0.2.4 and 0.3.1) is incompatible with
Node 0.12.0. The manual test adds no value at this point, so it has been
removed, including the dependencies (webkit-devtools-agent).
If you wish to check if the API works, launch demo.html,
set the global cors_api_url variable to your local instance,
enter an URL and press "GET" or "POST".
