-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changed value for hostname to allow for two failing tests to pass. Th… #14781
Conversation
Hi, @icarter09! Welcome and thanks for doing this! If it's not too much trouble, it would be great if you could take a moment to format the commit message according to https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#commit-message-guidelines. In particular, the first line of the commit message should be something like Thanks again! |
/cc @ncopa |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM if CI is green
(Also, if you're editing the commit message, maybe put |
I agree that this is better than the |
@Trott I can make the changes to the commit message if it hasn't already been changed. As well as add in the extra line you suggested. |
Looks like my rebase to amend the message is trying to bring in other commits. Let me know if this pull request should be reopened and fixed or a new one created. |
Reopening and fixing would be ideal. If you have any issues doing it feel free to ask a collaborator (I'm @gibfahn on twitter if you don't use IRC). Recording the existing commit here just in case something goes wrong: Patch:From d0e619382f07947e8a68fa8d80b7fd867170c930 Mon Sep 17 00:00:00 2001
From: icarter09 <icarter1391@gmail.com>
Date: Fri, 11 Aug 2017 23:04:41 -0400
Subject: [PATCH] test: use reserved invalid hostname for tests
---
test/parallel/test-net-better-error-messages-port-hostname.js | 4 ++--
test/parallel/test-net-connect-immediate-finish.js | 7 +++++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/test/parallel/test-net-better-error-messages-port-hostname.js b/test/parallel/test-net-better-error-messages-port-hostname.js
index 04974908c9..dac1714167 100644
--- a/test/parallel/test-net-better-error-messages-port-hostname.js
+++ b/test/parallel/test-net-better-error-messages-port-hostname.js
@@ -4,12 +4,12 @@ const net = require('net');
const assert = require('assert');
// Using port 0 as hostname used is already invalid.
-const c = net.createConnection(0, '***');
+const c = net.createConnection(0, 'this.hostname.is.invalid');
c.on('connect', common.mustNotCall());
c.on('error', common.mustCall(function(e) {
assert.strictEqual(e.code, 'ENOTFOUND');
assert.strictEqual(e.port, 0);
- assert.strictEqual(e.hostname, '***');
+ assert.strictEqual(e.hostname, 'this.hostname.is.invalid');
}));
diff --git a/test/parallel/test-net-connect-immediate-finish.js b/test/parallel/test-net-connect-immediate-finish.js
index 1006a62d33..1b65ce15ab 100644
--- a/test/parallel/test-net-connect-immediate-finish.js
+++ b/test/parallel/test-net-connect-immediate-finish.js
@@ -24,14 +24,17 @@ const common = require('../common');
const assert = require('assert');
const net = require('net');
-const client = net.connect({ host: '***', port: common.PORT });
+const client = net.connect({
+ host: 'this.hostname.is.invalid',
+ port: common.PORT
+});
client.once('error', common.mustCall((err) => {
assert(err);
assert.strictEqual(err.code, err.errno);
assert.strictEqual(err.code, 'ENOTFOUND');
assert.strictEqual(err.host, err.hostname);
- assert.strictEqual(err.host, '***');
+ assert.strictEqual(err.host, 'this.hostname.is.invalid');
assert.strictEqual(err.syscall, 'getaddrinfo');
}));
|
@icarter09 out of interest, what was the issue with the |
@gibfahn yes both of those tests were failing for me. |
Message is now fixed. Pull request is straightened out. Much props to @gibfahn for helping me untangle the mess I created. Learned what not to do and what to do going forward. |
@gibfahn Just in case it's detail that's helpful, the issue that @icarter09 was having with |
Landed in 0309619, welcome aboard! 🎉 |
PR-URL: #14781 Refs: https://tools.ietf.org/html/rfc2606#section-2 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
PR-URL: #14863 Refs: #14781 Refs: https://tools.ietf.org/html/rfc2606#section-2 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io>
PR-URL: nodejs/node#14781 Refs: https://tools.ietf.org/html/rfc2606#section-2 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Note that if your DNS is hijacked by your current ISP, which redirects requests to unknown hosts to their own server, like this:
then these tests could fail. This can be addressed by always using a trusted public DNS though (like this, although I am not using Google DNS since it is blocked in China ¯\(ツ)/¯). I wonder if this tip should be documented somewhere...maybe in the guides or |
@joyeecheung Have you seen this test fail that way?
These tests work for me with no network connectivity at all, so another option might be to disconnect from the network. |
Yes, these are the errors that I saw when I was with a DNS-hijacking ISP: See errors
Ah, that's a good (and simpler) solution as well. |
My ISP did that as well, but luckily, they allowed me to change that setting. |
PR-URL: #14781 Refs: https://tools.ietf.org/html/rfc2606#section-2 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
I just ran into this problem myself due to isp issues where I'm currently staying. I'm not convinced that the change is worth introducing this weird edge case, that I can say from first hand experience is very odd and not obvious to track down. I've backed this out of v8.x-staging / v8.5.0-proposal and would like to see this change reverted Thoughts? |
@addaleax Do you know whether or not this is a problem that your DNS test double can solve? |
We could solve this by using a public DNS server (e.g. the famous |
I don’t think so, because |
Oh, right, we never implemented a way to use resolvers with the rest of our API... |
@tniessen |
@bnoordhuis Yes, we could use that, but the signature of the callback of |
PR-URL: #14781 Refs: https://tools.ietf.org/html/rfc2606#section-2 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
PR-URL: #14781 Refs: https://tools.ietf.org/html/rfc2606#section-2 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
PR-URL: #14781 Refs: https://tools.ietf.org/html/rfc2606#section-2 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
…e tests in question were test-net-better-error-messages-port-hostname and test-net-connect-immediate-finish.
Instead of changing the test to permit 'ENOTFOUND' or 'EAI_AGAIN', the value '***' was changed to 'this.hostname.is.invalid'. The change is also reflected in the fact that RFC 2606 reserves the '.invalid' TLD for invalid domain names.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
node test package