Skip to content

http: defines all the fields in the constructor - #9116

Closed
vitkarpov wants to merge 1 commit into
nodejs:masterfrom
vitkarpov:issue-8912
Closed

http: defines all the fields in the constructor#9116
vitkarpov wants to merge 1 commit into
nodejs:masterfrom
vitkarpov:issue-8912

Conversation

@vitkarpov

Copy link
Copy Markdown
Contributor
Checklist
  • make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
  • commit message follows commit guidelines
Description of change

res and abort fields are now defined in the constructor and not suddenly appear during the runtime. This makes hidden class stable and the heap snapshot more verbose.

Ref: #8912
PR-URL: #9116

@nodejs-github-botnodejs-github-bot added the http Issues or PRs related to the http subsystem. label Oct 16, 2016
Comment threadlib/_http_client.js Outdated

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

This change doesn't affect anything, but I found two different ways across the single constructor: self and this. Seems it should be consistent but I don't know the agreement about it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@bnoordhuis didn't you mention in another issue recently that we should prefer this and an arrow function over self?

Comment threadlib/_http_client.js Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If we're setting this to zero now, we should both remove ClientRequest.prototype.aborted = undefined; and change the if (this.aborted === undefined) check to if (!this.aborted) below.

Comment threadlib/_http_client.js Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Perhaps we should also change delete req.res later in this file to req.res = null?

@vitkarpov

vitkarpov commented Oct 16, 2016

Copy link
Copy Markdown
ContributorAuthor

@mscdex made some fixes after review:

  • removed aborted from prototype, it's unnecessary anymore
  • the right check for this.aborted
  • do not delete res from object anymore, just null it

Also, started to use this, not self in the constructor

@mscdex

Copy link
Copy Markdown
Contributor

@vitkarpov

Copy link
Copy Markdown
ContributorAuthor

Guys, why do windows tests fail? Seems it's not the result of this changes, considering it's about JavaScript code, isn't it?

@mscdex

mscdex commented Oct 17, 2016

Copy link
Copy Markdown
Contributor

@vitkarpov In this case, the Windows failure is the result of a CI infrastructure issue and is unrelated to this PR.

I'm not sure why aix failed though, it seems it couldn't find the built node binary for some reason. /cc @mhdawson ?

The ARM failure looks unrelated.

@vitkarpov

Copy link
Copy Markdown
ContributorAuthor

Yep, I've noticed that some other prs behave the same.

@rvagg
rvaggforce-pushed the master branch 2 times, most recently from c133999 to 83c7a88CompareOctober 18, 2016 17:02
@vitkarpov

Copy link
Copy Markdown
ContributorAuthor

Guys, what's gonna happen with this pr? I'm ready to rebase the branch when it will be about to be merged, but I'm not sure about the process (there's not milestone tag or something).

@cjihrig

Copy link
Copy Markdown
Contributor

Minimally, this needs a rebase, collaborator approval, and a new CI run.

@vitkarpov

Copy link
Copy Markdown
ContributorAuthor

@cjihrig rebased

@mscdex

Copy link
Copy Markdown
Contributor

@cjihrigcjihrig added the semver-major PRs that contain breaking changes and should be released in the next major version. label Oct 28, 2016
@cjihrig

Copy link
Copy Markdown
Contributor

@mscdex

mscdex commented Jan 6, 2017

Copy link
Copy Markdown
Contributor

@vitkarpov
A couple of things to note:

  • All of these assignments (including the existing this._ended = false) need to happen earlier in the constructor before any possible early returns. I would suggest placing them before these lines in the constructor:
varcalled=false;if(self.socketPath){// ...
  • These also need to be added to the constructor:
this.timeoutCb=null;this.upgradeOrConnect=false;

@vitkarpov

Copy link
Copy Markdown
ContributorAuthor

@mscdex Done.

@mscdex

Copy link
Copy Markdown
Contributor

@mscdex

mscdex commented Jan 6, 2017

Copy link
Copy Markdown
Contributor

CI is green, except for an unrelated CI infrastructure failure.

LGTM.

/cc @nodejs/collaborators

@targos

Copy link
Copy Markdown
Member

I think there are additional properties to add:

  • this.parser = null
  • this.maxHeadersCount = undefined

Comment threadlib/_http_client.js Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It's usually helpful to add a little comment on these, as it helps in the long run (see _readableState as an example).

@vitkarpovvitkarpovJan 6, 2017

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

@mcollina I'm sorry, but I'm not sure I get it right, do you mean this comment?

@vitkarpov

Copy link
Copy Markdown
ContributorAuthor

I think there are additional properties to add

Hm, I greped a bit and found even more fields. Seems this needs to be processed the same way, doesn't it?

@jasnell@cjihrig Also, maybe it's a good idea to make some special setter-methods for such cases or it's overkill? (so the outer code doesn't set anything to request instance directly, because it's hard to control beyond)

@mscdex

mscdex commented Jan 6, 2017

Copy link
Copy Markdown
Contributor

@targos is right, those additional properties seem to also be used on the ClientRequest object, although I would suggest using null instead of undefined for maxHeadersCount since it makes it look more intentional.

@mscdex

mscdex commented Jan 6, 2017

Copy link
Copy Markdown
Contributor

Hm, I greped a bit and found even more fields. Seems this needs to be processed the same way, doesn't it?

@vitkarpovsocket and connection are already defined in OutgoingMessage's constructor, which is what ClientRequest inherits from.

@targos

Copy link
Copy Markdown
Member

btw I used Object.seal(this) at the end of the constructor and ran the tests to find the missing properties.

@vitkarpov

Copy link
Copy Markdown
ContributorAuthor

I would suggest using null instead of undefined for maxHeadersCount

@mscdex maybe it should be always a number and 2000 by default in constructor? (I'm not sure does this break anything, hope tests illuminate :)

@MylesBorins

Copy link
Copy Markdown
Contributor

As this has not been backported I'm setting to dont-land

darai0512 added a commit to darai0512/node that referenced this pull request Apr 30, 2018
In Refs, http.Server's maxHeadersCount field was defined in the
constructor to make hidden class stable and so on. Also in https.Server,
we can use maxHeadersCount the same as http via connectionListener. So,
defines it in the constructor and documentation.
Refs: nodejs#9116
addaleax pushed a commit that referenced this pull request May 5, 2018
In Refs, http.Server's maxHeadersCount field was defined in the
constructor to make hidden class stable and so on. Also in https.Server,
we can use maxHeadersCount the same as http via connectionListener. So,
defines it in the constructor and documentation.
Refs: #9116
PR-URL: #20359
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
MylesBorins pushed a commit that referenced this pull request May 8, 2018
In Refs, http.Server's maxHeadersCount field was defined in the
constructor to make hidden class stable and so on. Also in https.Server,
we can use maxHeadersCount the same as http via connectionListener. So,
defines it in the constructor and documentation.
Refs: #9116
PR-URL: #20359
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
MylesBorins pushed a commit that referenced this pull request May 8, 2018
In Refs, http.Server's maxHeadersCount field was defined in the
constructor to make hidden class stable and so on. Also in https.Server,
we can use maxHeadersCount the same as http via connectionListener. So,
defines it in the constructor and documentation.
Refs: #9116
PR-URL: #20359
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
MylesBorins pushed a commit that referenced this pull request May 9, 2018
In Refs, http.Server's maxHeadersCount field was defined in the
constructor to make hidden class stable and so on. Also in https.Server,
we can use maxHeadersCount the same as http via connectionListener. So,
defines it in the constructor and documentation.
Refs: #9116
PR-URL: #20359
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

httpIssues or PRs related to the http subsystem.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@vitkarpov@mscdex@cjihrig@targos@MylesBorins@jasnell@mcollina@nodejs-github-bot