EventEmitter memory leak when header option for User-Agent is included

[diffen]

This could be a server-side issue but it's rather strange because it only happens when sending a custom user agent string using the request module.

var request = require('request');
var url = 'http://www.bigassfans.com/case-studies/delphine-restaurant/';

request({
    url : url,
    followRedirect : false,
    headers: {
        'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36'
    }
}, function(error, response, html){
        console.log(response.statusCode);
        console.log(response.headers);
});

When you run this, notice the response statusCode is 302, which is weird because the Location header in the response is the requested page itself.

If you run this without the User-Agent header, it works as expected and you get a 200 OK response.

If you send the User-Agent but comment out the followRedirect : false option, you get this error

Warning: Possible EventEmitter memory leak detected. 11 pipe listeners added. Use emitter.setMaxListeners() to increase limit

[othiym23]

npm is now seeing this issue as well: npm/npm#13656

So far, it doesn't appear to break anything, but it leads to a lot of extraneous output from Node on install.

[othiym23]

(npm/npm#13656 (comment) is what points back to request, FWIW)

[othiym23]

It seems plausible that bf86f17 is related to this.

[iarna]

Specifically, I suspect that removing:

bf86f17#diff-ccc0734f65dd7a299409ff07d35be095L849

Exposed this. It's not causitive per se, it just removed the thing that was hiding the warning messages previously.

[diffen]

In my case, the cause of the problem was that the server kept redirecting the page to itself. The way they implemented it was that on every redirect they sent a cookie and then used the cookie to decide what content to serve the user on the next request. For requests without cookies, the page redirected to itself.

So for the request module, since cookies weren't enabled, this resulted into an infinite loop. I wonder if there's a way to fail safely in such cases.

[mhart]

In npm's case, the conversation is continued here I believe: npm/npm-registry-client#142

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kevinburkenotion]

If you're searching on Google and find this #3139 may provide an explanation, for the redirect behavior at least