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: verify method is a string #10111

Closed
wants to merge 5 commits into from
Closed

http: verify method is a string #10111

wants to merge 5 commits into from

Conversation

lucamaraschi
Copy link
Contributor

@lucamaraschi lucamaraschi commented Dec 4, 2016

Checklist
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

http

Description of change

Added strict check for http request method to be a string. If method is not a string (or undefined or null) a TypeError exceptions is thrown.
The method value is still defaulted to GET in the following cases:

  • method is undefined
  • method is null
    This fixes the http-client to crash if options.method in http.request was set to a number not equal to 0.

@nodejs-github-bot nodejs-github-bot added the http Issues or PRs related to the http subsystem. label Dec 4, 2016
if (_method !== undefined && _method !== null
&& typeof _method !== 'string') {
throw new TypeError('Method must be a string');
}
Copy link
Contributor

@mscdex mscdex Dec 4, 2016

Choose a reason for hiding this comment

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

For the best backwards compatibility (and to emulate the method value selection behavior below the typeof check), I think the undefined/null check should be removed and just test for truthiness:

if (options.method && typeof options.method !== 'string') {
  throw new TypeError('Method must be a string');
}

The reason being that options.method could be one of several non-truthy values, such as 0 and false.

Copy link
Contributor Author

@lucamaraschi lucamaraschi Dec 4, 2016

Choose a reason for hiding this comment

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

In this case if options.method is set to 0 results in a falsy value which is going to default the method to GET in the following check.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mscdex that would not fix the non-truthy values, confusing the defaulting of 0 values to GET.

Copy link
Contributor

Choose a reason for hiding this comment

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

Well, it's a difference between semver-ness. This change is definitely going to be semver-major as-is, but it could be semver-patch with the check I suggested. It's up to you.

@mscdex mscdex added the semver-major PRs that contain breaking changes and should be released in the next major version. label Dec 4, 2016
const assert = require('assert');
const http = require('http');

const expectedSuccesses = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Only the keys seem to be used. This could probably be an array...

http.request({ method: method, port: server.address().port }).end();
}

ok(undefined);
Copy link
Contributor

Choose a reason for hiding this comment

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

... and then you can loop over the array here. Right now, the number of times ok() is called is independent of methods.

function fail(input) {
assert.throws(() => {
http.request({ method: input, path: '/' }, common.fail);
}, /Method must be a string/);
Copy link
Contributor

Choose a reason for hiding this comment

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

If you want to be really strict, this could be /^TypeError: Method must be a string$/.

@@ -68,6 +68,11 @@ function ClientRequest(options, cb) {
self.socketPath = options.socketPath;
self.timeout = options.timeout;

const _method = options.method;
if (_method !== undefined && _method !== null
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be written as:

if (_method != null && typeof _method !== 'string')

If you don't choose to rewrite like that, the && should be moved to the previous line, and the second line should be lined up. I'm surprised the linter doesn't complain.

@lucamaraschi
Copy link
Contributor Author

@cjihrig and @mscdex I amended the PR adding your feedbacks.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 6, 2016

const _method = options.method;
if (_method != null && typeof _method !== 'string') {
throw new TypeError('Method must be a string');
}
var method = self.method = (options.method || 'GET').toUpperCase();
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably use options.method or _method consistently. Right now it's a mix.

Copy link
Member

Choose a reason for hiding this comment

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

The common._checkIsHttpToken() check on line 77 already includes a test to ensure method is a string.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 6, 2016

One CI failure looks unrelated.

@sam-github
Copy link
Contributor

Is this really semver-major? Wouldn't node have thrown an unexpected internal type error when it tried to use the method as a String, even though it wasn't? I understand when text of warning messages are changed it can break user-space, but user-space depending on something like undefined is not a function instead of a proper type error seems a bit more far fetched. Generally, people test for operation errors, not syntax errors.

Just asking for clarification here.

@targos
Copy link
Member

targos commented Dec 6, 2016

@sam-github See mscdex's comment here: #10111 (comment)
It's semver-major because before the change, if options.method was any falsy value, it would default to 'GET'. Now it throws (unless it's the empty string).
IMO the check should be changed so that we can remove the semver-major label.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 6, 2016

I think this is the correct thing to do moving forward. A second PR that is more backwards compatible might be good for Node 7 and earlier.

@jasnell
Copy link
Member

jasnell commented Dec 6, 2016

While I appreciate the new test, the common._checkIsHttpToken() check that is already there already validates that method is a string and already throws a TypeError if it is not.

@mscdex
Copy link
Contributor

mscdex commented Dec 6, 2016

@jasnell The issue though is that that common._checkIsHttpToken() check is happening after options.method || 'GET'. So if someone passes say false for options.method, it will be implicitly changed to 'GET'. This PR is just being more strict, presumably to catch programmer errors.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 6, 2016

In addition to what @mscdex said, if the method is not a string and is truthy, then an exception is thrown: TypeError: (options.method || "GET").toUpperCase is not a function

@jasnell
Copy link
Member

jasnell commented Dec 6, 2016

ok.. works for me :-)

@@ -68,7 +68,11 @@ function ClientRequest(options, cb) {
self.socketPath = options.socketPath;
self.timeout = options.timeout;

var method = self.method = (options.method || 'GET').toUpperCase();
const _method = options.method;
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we can just move the var method declaration up here and re-assign on line 75, that way we don't have a second variable for the same thing?

@@ -68,7 +68,11 @@ function ClientRequest(options, cb) {
self.socketPath = options.socketPath;
self.timeout = options.timeout;

var method = self.method = (options.method || 'GET').toUpperCase();
let method = options.method;
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you keep var. We haven't really made the switch to let in lib/ code for performance reasons.

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.

@cjihrig
Copy link
Contributor

cjihrig commented Dec 8, 2016

Landed in df39784. Thanks!

@cjihrig cjihrig closed this Dec 8, 2016
cjihrig pushed a commit that referenced this pull request Dec 8, 2016
Prior to this commit, it was possible to pass a truthy non-string
value as the HTTP method to the HTTP client, resulting in an
exception being thrown. This commit adds validation to the method.

PR-URL: #10111
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 18, 2017
Prior to this commit, it was possible to pass a truthy non-string
value as the HTTP method to the HTTP client, resulting in an
exception being thrown. This commit adds validation to the method.

PR-URL: nodejs#10111
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@jasnell jasnell mentioned this pull request Apr 4, 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