-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
url: allow use of URL with http.request and https.request #10638
Conversation
pathname: options.pathname, | ||
path: `${options.pathname}${options.search}`, | ||
href: options.href | ||
}; |
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.
I’m not sure how I feel about the code duplication here… could we make this a generic helper, possibly even hanging off the public url
module (if that makes transitioning url.parse → url.URL
easier)?
I would suggest adding it as the toJSON
method for URL
but I have looked at whatwg/url#137 and I’m not sure what to make of that other than that my idea would probably be silly/unrealistic/… :P
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.
Also – could this blocked be just executed independently of options instanceof url.URL
? It would mean using path: options.path || …
, but other than that, it should just work, no?
(If you feel unsure about these ideas, I can PR them myself later. If you feel they are horrible, say so and I won’t. ;))
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.
I can eliminate the duplication but having the instanceof and copying into a separate options is the most reliable and requires the fewest number of changes throughout the code.
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.
Those properties are enumerable (required by the spec) so a for-in
loop with some if
s would do I think?
EDIT: util._extend
doesn't apply because it only copies properties that are both enumerable and is own property. A helper function can loose the "isOwnProperty" bit but maybe not worth an additional abstraction anyway?
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.
I'd rather avoid doing the for-in loop in favor of keeping things more explicit and obvious. Also, as you point out, the auth
vs username
+password
would demonstrates that the properties do not match up one-to-one.
} else if (options instanceof url.URL) { | ||
options = { | ||
protocol: options.protocol, | ||
host: options.host, |
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.
Maybe a auth: `${options.username}:${options.password}`
here(and in http.js
too)?
EDIT: don't know why this comment appeared in another line, deleted that.
@@ -24,6 +24,18 @@ function ClientRequest(options, cb) { | |||
if (!options.hostname) { | |||
throw new Error('Unable to determine the domain name'); | |||
} | |||
} else if (options instanceof url.URL) { |
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.
If I understand correctly this makes using the new URL api and using additional options(like agent
) mutual exclusive?
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.
True, but that's already the case if you pass the URL as a string or the result of url.parse
. We can think later about a way to pass a URL object along with additional options but I don't think it should block this PR.
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.
Ah I should have make this one a comment, not a change request :/ Sorry.
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.
No worries!
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.
Yes, making those mutually exclusive is intentional. Attaching additional non-standard properties to the URL object is not something that we should promote. And as @targos points out, that is already the case when passing the URL as a string.
@addaleax @joyeecheung ... updated! PTAL |
'use strict'; | ||
|
||
require('../common'); | ||
|
||
const URL = require('url').URL; | ||
const assert = require('assert'); | ||
const urlToOptions = require('internal/url').urlToOptions; |
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.
Maybe this one deserves a separate test? The name of this test doesn't really match this API here.
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.
I'm not convinced that it matters too much either way, but there's no harm in separating it out.
LGTM. The tests could be split in another PR anyway. |
PR-URL: #10638 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Michal Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Landed in 0f62ee6 |
PR-URL: nodejs#10638 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Michal Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: nodejs#10638 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Michal Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: #10638 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Michal Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: nodejs#10638 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Michal Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: nodejs#10638 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Michal Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Notable changes: * crypto: * ability to select cert store at runtime (Adam Majer) #8334 * Use system CAs instead of using bundled ones (Adam Majer) #8334 * deps: * upgrade npm to 4.1.2 (Kat Marchán) #11020 * upgrade openssl sources to 1.0.2k (Shigeki Ohtsu) #11021 * doc: add basic documentation for WHATWG URL API (James M Snell) #10620 * process: add NODE_NO_WARNINGS environment variable (cjihrig) #10842 * url: allow use of URL with http.request and https.request (James M Snell) #10638 PR-URL: #11062
Notable changes: * crypto: * ability to select cert store at runtime (Adam Majer) #8334 * Use system CAs instead of using bundled ones (Adam Majer) #8334 * deps: * upgrade npm to 4.1.2 (Kat Marchán) #11020 * upgrade openssl sources to 1.0.2k (Shigeki Ohtsu) #11021 * doc: add basic documentation for WHATWG URL API (James M Snell) #10620 * process: add NODE_NO_WARNINGS environment variable (cjihrig) #10842 * url: allow use of URL with http.request and https.request (James M Snell) #10638 PR-URL: #11062
options.port = Number(url.port); | ||
} | ||
if (url.username || url.password) { | ||
options.auth = `${url.username}:${url.password}`; |
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.
This doesn't support new URL("http://0:0@hostname/")
Allow the new URL object to be used with
http.request()
andhttps.request()
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
http, https