After thinking about it some more it's probably mostly only useful to
see the output when the tests are hanging. Otherwise there's a lot of
noise about Jest child processes and pipes.
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.
