Skip to content
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

http: add type checking for hostname #12494

Closed
wants to merge 1 commit into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Apr 18, 2017

Add type checking for options.hostname / options.host Maintains the use of undefined and null for default localhost, but other falsy values (like false, 0 and NaN) are rejected.

Refs: #12488

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

http

@jasnell jasnell added http Issues or PRs related to the http subsystem. semver-major PRs that contain breaking changes and should be released in the next major version. labels Apr 18, 2017
@nodejs-github-bot nodejs-github-bot added the http Issues or PRs related to the http subsystem. label Apr 18, 2017
@@ -65,6 +65,14 @@ function isInvalidPath(s) {
return false;
}

function validateHost(host) {
if (host !== undefined && host !== null && typeof host !== 'string') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first two conditionals can be shortened to just host != null or host != undefined.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah... that's fine. I'm not a fan of != for that but shorter is better.

Copy link
Contributor

@mscdex mscdex Apr 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be more efficient too, I have not checked how V8 compiles the two different methods of checking.

function validateHost(host) {
if (host !== undefined && host !== null && typeof host !== 'string') {
throw new TypeError(
'hostname must either be a string, undefined or null');
Copy link
Contributor

@mscdex mscdex Apr 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we might use: "hostname"/"host" must either be a string, undefined, or null to keep with the theme of quoting property names?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, right... good catch :-)

@jasnell
Copy link
Member Author

jasnell commented Apr 18, 2017

@mscdex Updated

Copy link
Contributor

@cjihrig cjihrig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with a question.


['', undefined, null].forEach((v) => {
assert.doesNotThrow(() => {
http.request({hostname: v}).on('error', common.noop);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the common.noop here? I'd think we'd either want mustCall() or mustNotCall().

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main part that this is testing is that the call to http.request() does not throw synchronously. The fact that it will emit the error event is non-sequential to this particular test. This is set simply to avoid the unhandled error exception.

throw new TypeError(
'hostname must either be a string, undefined or null');
'"hostname" must either be a string, undefined or null');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we include "host" as well, since this same function is used for both?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was stewing over that. Not sure. I'm fine with doing so just not sure if we should

@@ -65,6 +65,15 @@ function isInvalidPath(s) {
return false;
}

function validateHost(host) {
// eslint-disable-next-line eqeqeq
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm not wrong this can be removed if host != null is used instead of host != undefined.

@jasnell
Copy link
Member Author

jasnell commented Apr 19, 2017

@mscdex @lpinca ... updated!

@jasnell
Copy link
Member Author

jasnell commented Apr 20, 2017

@nodejs/ctc ... PTAL


// All of these values should cause http.request() to throw synchronously
// when passed as the value of either options.hostname or options.host
const vals = [{}, [], NaN, Infinity, -Infinity, true, false, 1, new Date()];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe include 0 as well, since it would have been treated as a false-y value?

// when passed as the value of either options.hostname or options.host
const vals = [{}, [], NaN, Infinity, -Infinity, true, false, 1, new Date()];

function errCheck(name) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is not doing any checks actually

// These values are OK and should not throw synchronously
['', undefined, null].forEach((v) => {
assert.doesNotThrow(() => {
http.request({hostname: v}).on('error', common.noop);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not common.mustNotCall() here?

Copy link
Member

@lpinca lpinca Apr 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasnell's reply on a comment above for same question

The main part that this is testing is that the call to http.request() does not throw synchronously. The fact that it will emit the error event is non-sequential to this particular test. This is set simply to avoid the unhandled error exception.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmm, makes sense. Cool then.

Add type checking for options.hostname / options.host
Maintains the use of `undefined` and `null` for default `localhost`,
but other falsy values (like `false`, `0` and `NaN`) are rejected.
@jasnell
Copy link
Member Author

jasnell commented Apr 24, 2017

@jasnell
Copy link
Member Author

jasnell commented Apr 24, 2017

Linting error was from an unrelated commit

jasnell added a commit that referenced this pull request Apr 24, 2017
Add type checking for options.hostname / options.host
Maintains the use of `undefined` and `null` for default `localhost`,
but other falsy values (like `false`, `0` and `NaN`) are rejected.

PR-URL: #12494
Ref: #12488
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Ali Ijaz Sheikh <[email protected]>
@jasnell
Copy link
Member Author

jasnell commented Apr 24, 2017

Landed in 85a4e25

addaleax added a commit to addaleax/node that referenced this pull request Apr 25, 2017
This test would currently create HTTP requests to localhost:80
and would time out on machines that actually had an server listening
there.

To address that, `end()` the requests that are generated.

PR-URL: nodejs#12627
Ref: nodejs#12494
addaleax added a commit that referenced this pull request Apr 27, 2017
This test would currently create HTTP requests to localhost:80
and would time out on machines that actually had an server listening
there.

To address that, `end()` the requests that are generated.

PR-URL: #12627
Ref: #12494
Reviewed-By: Daniel Bevenius <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@jasnell jasnell mentioned this pull request May 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
http Issues or PRs related to the http subsystem. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants