ENOTFOUND, Domain name not found

[ewoutmeyns]

I ran into a problem while trying to use Nock in an existing node.js script that sends a request to a local node server.

I have reduced the problem to the code below. My server is running on localhost:5000.

Executing this will work:

http = require 'http'

options = 
  host: '127.0.0.1',
  port: 5000,
  path: '/'

http.get options, (error, reply) ->
  console.log error
  console.log reply

But from the moment I require Nock, an error raises:

http = require 'http'
nock = require 'nock'

options = 
  host: '127.0.0.1',
  port: 5000,
  path: '/'

http.get options, (error, reply) ->
  console.log error
  console.log reply

events.js:45
throw arguments[1]; // Unhandled 'error' event
^
Error: ENOTFOUND, Domain name not found
at IOWatcher.callback (dns.js:74:15)

[ewoutmeyns]

Important to note is that the same code, but with an external host, works perfect:

http = require 'http'
nock = require 'nock'

options = 
  host: 'www.google.be',
  port: 80,
  path: '/'

http.get options, (error, reply) ->
  console.log error
  console.log reply

[deitch]

+1. I have the exact same problem, just killed an hour+ looking for it in other libraries.

Happy to take a workaround...

[deitch]

FYI, problem first appears in 0.10.6. I tried everything from 0.10.1 (where it used to work for me), up to 0.10.8, and it appears with 0.10.6

[deitch]

And one more for you: It only occurs when you specify a port other than 80 on the http.get. Specifying port 80 or no port works:

var http = require('http');
require('nock');

http.get({host:"localhost"}, function(res) {
console.log("NOPORT response: " + res.statusCode);
}).on('error', function(e) {
console.log("NOPORT error: " + e.message);
});

http.get({host:"localhost",port:80}, function(res) {
console.log("PORT80 response: " + res.statusCode);
}).on('error', function(e) {
console.log("PORT80 error: " + e.message);
});

http.get({host:"localhost",port:81}, function(res) {
console.log("PORT81 response: " + res.statusCode);
}).on('error', function(e) {
console.log("PORT81 error: " + e.message);
});

Will give the following output:

PORT81 error: getaddrinfo ENOENT
PORT80 response: success
NOPORT response: success

It appears to have something to do with commit 8797e28

[deitch]

I got it. It is that one. And the problem is in intercept.js LL42-64 or LL 93-134.

Here is what is wrong. In line 93-134 (or so), http.request is overridden. Makes sense. Then nock checks if it has interceptorsFor given the options. If it finds, it uses those, else it just launches the oldRequest.

BUT: if it is anything other than a non-standard port (http:80 or https:443), it changes the original options object. So if options was the first part, it transforms to the second part

{host:"localhost",port:80} -> {host:"localhost",port:80}
{host:"localhost",port:81} -> {host:"localhost:81"} // here is the problem

It then finds no interceptor and passes the request on to oldRequest, but it now changed the original options.

What it should do is duplicate the options, then modify those, so that the original stays.

[pgte]

Thanks for the report, released nock v0.11.4

[deitch]

Speedy!

Still got a different bug. Look at intercept.js L69:

console.log('basePath:', basePath)

I don't think you want that console.log in release... :-)

[pgte]

Oops, thanks for noticing it, removed in nock v0.11.5.

[deitch]

No prob. Putting in.

"nock":">=0.11.5"

now.

On Mar 28, 2012, at 11:05 AM, Pedro Teixeira
reply@reply.github.com
wrote:

Oops, thanks for noticing it, removed in nock v0.11.5.

---

Reply to this email directly or view it on GitHub:
#52 (comment)

[ewoutmeyns]

Thank you pgte & deitch for working out a solution!

[deitch]

Pleasure. Glad I was able to find it and proffer a solution, rather than just complain, "it doesn't work!" :-)

Just tested 0.11.5 and works great.

[pgte]

Yes, that type of report is great, helped a lot.

The only best thing is a pull request with the fix ;)

[deitch]

Ok, true, but it seemed silly to do a whole clone/fix/pull just for that.
Well, maybe not; next time... :-)

On Fri, Mar 30, 2012 at 9:22 AM, Pedro Teixeira <
reply@reply.github.com

wrote:

Yes, that type of report is great, helped a lot.

The only best thing is a pull request with the fix ;)

---

Reply to this email directly or view it on GitHub:
#52 (comment)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue and add a reference to this one if it’s related. Thank you!