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

https: allow url and options to be passed to https.request #22003

Closed
wants to merge 1 commit into from

Conversation

rubys
Copy link
Member

@rubys rubys commented Jul 27, 2018

This completes #21616 by adding https which was inadvertently left out.

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

@nodejs-github-bot nodejs-github-bot added http Issues or PRs related to the http subsystem. https Issues or PRs related to the https subsystem. labels Jul 27, 2018
@mscdex
Copy link
Contributor

mscdex commented Jul 27, 2018

I would prefer avoiding adding new (underscore-prefixed) functions to the prototype.

I believe this could be resolved at least by one of:

  • Making HttpsClientRequest have no additional methods and checking this.constructor === HttpsClientRequest
  • Allow passing a 4th option to ClientRequest that if not undefined, must be a private symbol indicating an https client request
  • Make the few changes needed to the original code in https to support both url and options

Also, I think the commit message should technically have an https: prefix?


ClientRequest.prototype._defaultAgent = function() {
return Agent.globalAgent;
};
Copy link
Member

Choose a reason for hiding this comment

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

I would avoid exposing those two directly. Maybe we should move them under a private Symbol?

@rubys rubys force-pushed the https_url_options branch from 86109e4 to 9f8f5d9 Compare July 29, 2018 05:01
@rubys rubys changed the title http: allow url and options to be passed to https.request https: allow url and options to be passed to https.request Jul 29, 2018
return new ClientRequest(options, cb);
args.unshift(options);

return new ClientRequest(...args);
Copy link
Contributor

@mscdex mscdex Jul 29, 2018

Choose a reason for hiding this comment

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

Last I checked, this was still significantly slower in V8 I think?

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed in Node 8.3? See https://github.com/davidmarkclements/v8-perf

Here’s the takeaway: if we want to write performant code around processing function inputs as an array (which in my experience seems fairly common), then in Node 8.3 and up we should use the spread operator.

Responding to your original suggestions:

Making HttpsClientRequest have no additional methods and checking this.constructor === HttpsClientRequest

The issue is that without additional methods, it never would be called... unless we duplicated the entire constructor.

Allow passing a 4th option to ClientRequest that if not undefined, must be a private symbol indicating an https client request

This will impact the ability to add future arguments. And we are currently dealing with three arguments, all optional...

Make the few changes needed to the original code in https to support both url and options

I went this way for now.

The other option:

Maybe we should move them under a private Symbol?

This is clean and would work. The symbols would need to be exported by lib/_http_client.js

Copy link
Member

Choose a reason for hiding this comment

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

This is clean and would work. The symbols would need to be exported by lib/_http_client.js

I would prefer it. Unfortunately there is a lot of monkey patching around core methods, and I would prefer this would be as private as possible. I would not block this for it.

If you feel strongly about going _, then ok.

Copy link
Member Author

Choose a reason for hiding this comment

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

@mcollina I'm not following.... in particular, I'm not sure what 'it' refers to.

Should I go back to the previous approach of subclassing ClientRequest for https, and introducing two new methods, this time with the method names being Symbols? My thoughts are that that approach is more understandable and maintainable.

Or would you prefer the current approach which duplicates a bit of code, but doesn't introduce any new methods. My thoughts are that approach is more private.

Copy link
Member

Choose a reason for hiding this comment

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

I was actually commenting on some old code. The current approach is fine. LGTM

Copy link
Contributor

@mscdex mscdex Jul 29, 2018

Choose a reason for hiding this comment

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

Making HttpsClientRequest have no additional methods and checking this.constructor === HttpsClientRequest

The issue is that without additional methods, it never would be called... unless we duplicated the entire constructor.

@rubys I'm not sure what you mean, HttpsClientRequest would extend from ClientRequest and be empty itself (no explicit constructor or additional methods). Then inside ClientRequest, checking this.constructor like:

var defaultAgent = options._defaultAgent ||
                   (this.constructor === https[ClientRequestSym]
                    ? https.globalAgent : Agent.globalAgent);

Copy link
Member Author

Choose a reason for hiding this comment

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

@McDex Fair point, but making that work would involve a circular require.

Copy link
Contributor

Choose a reason for hiding this comment

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

@rubys Not if it's lazy loaded.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

@mcollina
Copy link
Member

@Trott Trott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jul 30, 2018
@Trott
Copy link
Member

Trott commented Jul 30, 2018

@Trott Trott removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Aug 1, 2018
@Trott
Copy link
Member

Trott commented Aug 1, 2018

I removed the author ready label because I'm not sure if the comments from @mscdex are blocking or if @rubys would want to address them first before landing regardless. Feel free to add the label back or to land the thing if I'm wrong. It's possible I'm being overly cautious.

@rubys
Copy link
Member Author

rubys commented Aug 1, 2018

I believe that this is ready to land. @McDex and @mcollina had similar concerns on my first implementation and collectively provided four alternatives. I selected and implemented @McDex's third option, and @mcollina approved the approach.

What remains is side conversation as to whether @McDex's first suggestion could also be made to work (it could, but wouldn't be as clear/straightforward as the third suggestion, in my opinion). Assuming that @McDex is still comfortable with his third suggestion (he should be, he suggested it :-)), I think we are good to go.

@mscdex
Copy link
Contributor

mscdex commented Aug 1, 2018

I don't have a problem adding the missing code to https. My last comments were about a preferred way
for avoiding the code duplication.

@Trott Trott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Aug 1, 2018
@Trott
Copy link
Member

Trott commented Aug 1, 2018

@mscdex Just to make sure I'm understanding: You're OK with this landing without the lazy loading? That can be implemented in a subsequent PR or not at all and that's OK?

@mscdex
Copy link
Contributor

mscdex commented Aug 1, 2018

@Trott My comment about the https lazy loading and constructor checking was one possible solution, one that would avoid the need to duplicate code. I am fine with either that or adding the missing code in https, which is what the PR does as of this writing.

@Trott
Copy link
Member

Trott commented Aug 1, 2018

Landed in 19aa41c

@Trott Trott closed this Aug 1, 2018
Trott pushed a commit to Trott/io.js that referenced this pull request Aug 1, 2018
PR-URL: nodejs#22003
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@targos targos added backport-requested-v10.x and removed author ready PRs that have at least one approval, no pending requests for changes, and a CI started. labels Aug 1, 2018
@targos
Copy link
Member

targos commented Aug 1, 2018

This should be backported along with #21616

targos pushed a commit to targos/node that referenced this pull request Aug 2, 2018
PR-URL: nodejs#22003
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
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. https Issues or PRs related to the https subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants