This changes adds a new method called `.canTry` to the rate limiter to check if
there are tokens remaining in the bucket.
It also adds suggestions from @oxy to make sure the user can brute force past
the rate limiter.
Before, we weren't checking if a login was successful before counting it
against the rate limiter.
With this change, we only count unsuccessful logins against the rate limiter.
We did this because this was a bug but also because it caused problems with our
e2e tests hitting the rate limit.
Any json or urlencoded request bodies were being consumed by body-parser
before they could be proxied. That's why requests without Content-Type
were proxied correctly as body-parser would not consume their body.
This allows the http-proxy package to passthrough the request body correctly
in all instances.
Closes#2377
This breaks --proxy-path-passthrough
However, we still need this when that code is disabled as many apps will
issue absolute redirects and expect the proxy to rewrite as appropriate.
e.g. Go's http.Redirect will rewrite relative redirects as absolute!
See https://golang.org/pkg/net/http/#Redirect
This had me very confused for quite a while until I did a binary search
inspection on route/index.ts. Only with the heart.beat line commented
out did my tests pass without leaking.
They weren't leaking fds but just this heartbeat timer and node of
course prints just fds that are active when it detects some sort of leak
I guess and that made the whole thing very confusing. These fds are not
leaked and will close when node's event loop detects there are no more
callbacks to run.
no of handles 3
tcp stream {
fd: 20,
readable: false,
writable: true,
address: {},
serverAddr: null
}
tcp stream {
fd: 22,
readable: false,
writable: true,
address: {},
serverAddr: null
}
tcp stream {
fd: 23,
readable: true,
writable: false,
address: {},
serverAddr: null
}
It kept printing the above text again and again for 60s and then the
test binary times out I think. I'm not sure if it was node printing the
stuff above or if it was a mocha thing. But it was really confusing...
cc @code-asher for thoughts on what was going on.
edit: It was the leaked-handles import in socket.test.ts!!!
Not sure if we should keep it, this was really confusing and misleading.
I removed this under the impression the default was to allow it anywhere
but that's not the case. Since the service worker was already registered
in my browser I never got the error during testing.
This is mostly so we don't have to do any wacky patching but it also
makes it so we don't have to keep checking if the request is a web
socket request every time we add middleware.
Joe Previte