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: specify _implicitHeader in OutgoingMessage #7949

Closed
wants to merge 1 commit into from

Conversation

yorkie
Copy link
Contributor

@yorkie yorkie commented Aug 2, 2016

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

http

Description of change

I saw "lib/_http_outgoing.js" uses _implicitHeader function 3 times: line1, line2 and line3. But not searched this method defined at OutgoingMessage.prototype, found this method is defined at its children.

@nodejs-github-bot nodejs-github-bot added the http Issues or PRs related to the http subsystem. label Aug 2, 2016
@cjihrig
Copy link
Contributor

cjihrig commented Aug 2, 2016

I'd word as _implicitHeader() method is not implemented to match the recent change to writable stream's _write() method, but other than that, LGTM if the CI is happy.

@yorkie
Copy link
Contributor Author

yorkie commented Aug 2, 2016

Fixed the wording and rebased :-)

CI: https://ci.nodejs.org/job/node-test-pull-request/3510

@mscdex
Copy link
Contributor

mscdex commented Aug 2, 2016

Is this necessary since OutgoingMessage is an internal thing?

@cjihrig
Copy link
Contributor

cjihrig commented Aug 2, 2016

Probably not. But I don't think it's a bad sanity check.

@Trott
Copy link
Member

Trott commented Aug 2, 2016

No opinion on this change, but if we do land it, please add a test before landing, since there's nothing that will exercise this code otherwise. At a minimum, I'd think we could do something as simple as:

assert.throws(http.OutgoingMessage.prototype._implicitHeader);

@Trott
Copy link
Member

Trott commented Aug 2, 2016

Small nit: All the var instances in the test can be const.

@yorkie
Copy link
Contributor Author

yorkie commented Aug 2, 2016

Is this necessary since OutgoingMessage is an internal thing?

@mscdex @Trott I proposed this change when reading "lib/_http_outgoing.js" and thought that the internal OutgoingMessage with a predefined _implicitHeader() would be better readable.

And @Trott, I have also added the simple test file :-)

var ServerResponse = http.ServerResponse;

assert.throws(OutgoingMessage.prototype._implicitHeader);
assert.ok(typeof ClientRequest.prototype._implicitHeader === 'function');
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Maybe use strictEqual() instead?:

assert.strictEqual(typeof ClientRequest.prototype._implicitHeader, 'function');

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed at 2c88993, thanks :-)

@yorkie
Copy link
Contributor Author

yorkie commented Aug 3, 2016

@Trott looks good to you now? If yes I will run a CI again, thank you :-)

@Trott
Copy link
Member

Trott commented Aug 3, 2016

The test looks good to me.

@yorkie
Copy link
Contributor Author

yorkie commented Aug 3, 2016

@jasnell
Copy link
Member

jasnell commented Aug 3, 2016

LGTM

Thinking out loud: I've been wondering about the possibility of creating a new InternalError subclass of Error specifically for these kinds of internal errors. Specifically, these are things that generally should not happen but depend on some internal, non-public aspect of Node.js' implementation. Having an explicit InternalError type of error would allow us to make that more explicit.

@Trott
Copy link
Member

Trott commented Aug 3, 2016

@jasnell IMO that's what an AssertionError is for. EDIT: OK, or maybe not...

@cjihrig
Copy link
Contributor

cjihrig commented Aug 3, 2016

I think I'd be -1 to adding InternalError. I think we should use the existing error types where appropriate.

@yorkie
Copy link
Contributor Author

yorkie commented Aug 3, 2016

Perhaps we use assert instead of throwing error might be proper here? it would throw the AssertionError?

@cjihrig
Copy link
Contributor

cjihrig commented Aug 3, 2016

I don't think asserting is the right thing to do here, as this is an unconditional error.

@jasnell
Copy link
Member

jasnell commented Aug 3, 2016

Ok, I'm good with this as it is and definitely understand @cjihrig's argument :-)

@yorkie
Copy link
Contributor Author

yorkie commented Aug 3, 2016

So keep using Error will be fine with you @cjihrig @Trott @jasnell, or you are +1 on specific throws of AssertionError?

@jasnell
Copy link
Member

jasnell commented Aug 3, 2016

+1 on keeping Error

@yorkie
Copy link
Contributor Author

yorkie commented Aug 3, 2016

Okay, and the CI seems to be green, how can we land this, should I land this by myself :-)

@Trott
Copy link
Member

Trott commented Aug 3, 2016

Leave it open for another day so that it's open for at least 48 hours before landing. If no one has any objections after the PR has been open for 48 hours, then the two LGTMs you already have are enough and you can land it yourself at that time.

PR-URL: nodejs#7949
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
yorkie added a commit that referenced this pull request Aug 5, 2016
PR-URL: #7949
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@yorkie
Copy link
Contributor Author

yorkie commented Aug 5, 2016

Landed at 99296ee, this is my first real contribution as a collaborator, so correct me if I'm wrong, thanks :-)

@yorkie yorkie closed this Aug 5, 2016
@yorkie yorkie deleted the http/improve branch August 5, 2016 15:29
@jasnell
Copy link
Member

jasnell commented Aug 5, 2016

The commit looks great @yorkie ! :-)

@cjihrig cjihrig mentioned this pull request Aug 8, 2016
cjihrig pushed a commit that referenced this pull request Aug 10, 2016
PR-URL: #7949
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@cjihrig cjihrig mentioned this pull request Aug 11, 2016
@MylesBorins
Copy link
Contributor

want confirmation that this should be backported. it adds a new throw, but it would throw anyways correct? Just dug into the code and afaict the function seems unimplemented in OutgoingMessage or it's parent class Stream.

@yorkie
Copy link
Contributor Author

yorkie commented Oct 1, 2016

@thealphanerd it should be implemented at https://github.com/nodejs/node/blob/master/lib/_http_client.js#L217-L220, its children class.

@MylesBorins
Copy link
Contributor

@nodejs/lts should we backport this?

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants