-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
[8.x] http2: expose http2 by default, add NODE_NO_HTTP2 #15685
Conversation
/cc @ofrobots @MylesBorins @mcollina @nodejs/http2 @nodejs/lts |
This is something that is not part of our current semver policy. Is this a semver-major change or not? @nodejs/tsc, what do you think? I fear this would also set a precedence for node core obscuring modules from the ecosystem without a semver-major change. Considering the fact that the http2 maintainer is ok in giving up the name, I am less worried about the impact of this change. The new home of them module is https://www.npmjs.com/package/http2.js - if I understand the threads correctly. @nwgh what do you think? |
Given that http2 is experimental still, it definitely falls outside the semver rules. Fortunately, we're not introducing new modules very often so hopefully this won't be something we have to deal with that often :-) |
I know its really late in the game to bring up things like this.... but was |
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.
LGTM
Tiny language nit included, but not blocking. There are a handful of tests that kept empty comments at the top which seems a bit odd
@@ -281,6 +277,10 @@ with small\-icu support. | |||
When set to \fI1\fR, process warnings are silenced. | |||
|
|||
.TP | |||
.BR NODE_NO_HTTP2 =\fI1\fR | |||
When set to \fI1\fR, the http2 module is suppressed. |
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.
s/supressed/not included in the runtime?
Not 100% that "supressed" gets the message across
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.
Suggestion: the 'http2' module is not exposed by the runtime
If decided to change should mirror in doc/api/cli.md:440 and src/node.cc:3832
@@ -1,4 +1,4 @@ | |||
// Flags: --expose-http2 | |||
// |
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.
is there a reason the comment remains?
@@ -1,8 +0,0 @@ | |||
// The --expose-http2 flag is not set |
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.
should we inverse this test to ensure it works? Or is that superfluous
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.
largely superfluous, but that does remind me that I need to add a test for the env var :-)
@mcollina et al - I'd be totally fine with this change from a naming standpoint. FTR, the http2.js npm module is a fork that has some bugfixes for newer nodes that I've been hesitant to take on the main node-http2 module (not because I think they're incorrect, but because I have some integration testing on that module that's all done manually, so the burden on taking pull requests is much, much higher - I'm trying to get that automated, but it's slow going). |
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.
doc suggestion
@@ -281,6 +277,10 @@ with small\-icu support. | |||
When set to \fI1\fR, process warnings are silenced. | |||
|
|||
.TP | |||
.BR NODE_NO_HTTP2 =\fI1\fR | |||
When set to \fI1\fR, the http2 module is suppressed. |
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.
Suggestion: the 'http2' module is not exposed by the runtime
If decided to change should mirror in doc/api/cli.md:440 and src/node.cc:3832
General context: |
b980892
to
e4c6698
Compare
@@ -9,9 +9,6 @@ can be accessed using: | |||
const http2 = require('http2'); | |||
``` | |||
|
|||
*Note*: Node.js must be launched with the `--expose-http2` command line flag | |||
in order to use the `'http2'` module. |
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 think this might still be useful as information in a YAML changes:
entry?
{ | ||
std::string text; | ||
config_expose_http2 = | ||
!(SafeGetenv("NODE_NO_HTTP2", &text) && text[0] == '1'); |
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 think we had a similar discussion like this, but this would currently make a distinction between NODE_NO_HTTP2=19
and NODE_NO_HTTP2=20
. Why not just … && text == "1"
?
@jasnell would you be able to rebase? @nodejs/tsc @nodejs/release can you please chime in |
e4c6698
to
b22014e
Compare
To me I think that http2 is experimental is not pertinent. This breaks end user code regardless of whether they were using the experimental support or not. As such I think the core question is whether breaking users of an external module is ok in this case, and if in general we consider adding APIs that obscure existing modules semver or not. |
Is it worth considering
|
7a74504
to
97f7590
Compare
@sam-github ... renaming the module really is not necessary. The author of the original module on npm has already agreed to hand it over and has already published a deprecated version. Users are already writing code using |
If The TSC might at their discretion decide this is worth doing in a release stream like 8.x that is not yet LTS. I'm not sure @nodejs/lts will be keen to make that kind of breaking change in 6.x, though, so if And of course, existing (EDIT: This is the last chance, I think, to look forward to the LTS proposal, and I think a number of issues about backwards compatibility become non-issues by renaming now. /cc @ofrobots |
@jasnell @sam-github @nwgh Just noticed that the |
engines is advisory (https://docs.npmjs.com/files/package.json#engines), but would be good to have set. It shouldn't be |
I'm more than happy to change the engine version in the http2 npm package to whatever the appropriate 8.x.y is for when this lands. Just need someone to inform me what that is/will be :) |
9eb991a
to
6f42b68
Compare
From the discussion in the TSC meeting (nodejs/TSC#384) this seems reasonable to me. |
I will rebase this today and get it landed tomorrow |
Make `--expose-http2` a non-op, Expose http2 by default. Add `NODE_NO_HTTP2=1` to suppress http2
Remove the --expose-http2 flag from tests and benchmarks
8c39761
to
9ccf0af
Compare
This is rebased. |
Make `--expose-http2` a non-op, Expose http2 by default. Add `NODE_NO_HTTP2=1` to suppress http2 PR-URL: #15685 Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Evan Lucas <[email protected]>
Remove the --expose-http2 flag from tests and benchmarks PR-URL: #15685 Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Evan Lucas <[email protected]>
@nodejs/tsc as this has landed in staging it is ready to go in the next release, which would be tomorrow. Due to the community concerns should we back this out? |
building on the last message. I currently have intent to ship http2 without a flag tomorrow. Opening a new issue |
Notable Changes: * crypto: - expose ECDH class #8188 * http2: - http2 is now exposed by defualt without the need for a flag #15685 - a new environment varible NODE\_NO\_HTTP2 has been added to allow userland http2 to be required #15685 - support has been added for generic `Duplex` streams #16269 * module: - resolve and instantiate loader pipeline hooks have been added to the ESM lifecycle #15445 * zlib: - CVE-2017-14919 - In zlib v1.2.9, a change was made that causes an error to be raised when a raw deflate stream is initialized with windowBits set to 8. On some versions this crashes Node and you cannot recover from it, while on some versions it throws an exception. Node.js will now gracefully set windowBits to 9 replicating the legacy behavior to avoid a DOS vector. https://github.com/nodejs-private/node-private/pull/95 PR-URL: https://github.com/nodejs-private/node-private/pull/98
Notable Changes: * crypto: - expose ECDH class nodejs/node#8188 * http2: - http2 is now exposed by defualt without the need for a flag nodejs/node#15685 - a new environment varible NODE\_NO\_HTTP2 has been added to allow userland http2 to be required nodejs/node#15685 - support has been added for generic `Duplex` streams nodejs/node#16269 * module: - resolve and instantiate loader pipeline hooks have been added to the ESM lifecycle nodejs/node#15445 * zlib: - CVE-2017-14919 - In zlib v1.2.9, a change was made that causes an error to be raised when a raw deflate stream is initialized with windowBits set to 8. On some versions this crashes Node and you cannot recover from it, while on some versions it throws an exception. Node.js will now gracefully set windowBits to 9 replicating the legacy behavior to avoid a DOS vector. nodejs-private/node-private#95 PR-URL: nodejs-private/node-private#98
I know this is kinda a side topic but I am still having issues importing http2 w/webpack. Any advice or direction toward resources would be much appreciated. Node Version: 8.8.1 |
I assume they aren't meant to be there. Refs: nodejs#15685
I assume they aren't meant to be there. PR-URL: #16631 Refs: #15685 Reviewed-By: Anatoli Papirovski <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
@mgibson1187 was your issue resolved? Did you try the webpack repo (https://github.com/webpack/webpack/issues)? |
Notable Changes: * crypto: - expose ECDH class nodejs/node#8188 * http2: - http2 is now exposed by defualt without the need for a flag nodejs/node#15685 - a new environment varible NODE\_NO\_HTTP2 has been added to allow userland http2 to be required nodejs/node#15685 - support has been added for generic `Duplex` streams nodejs/node#16269 * module: - resolve and instantiate loader pipeline hooks have been added to the ESM lifecycle nodejs/node#15445 * zlib: - CVE-2017-14919 - In zlib v1.2.9, a change was made that causes an error to be raised when a raw deflate stream is initialized with windowBits set to 8. On some versions this crashes Node and you cannot recover from it, while on some versions it throws an exception. Node.js will now gracefully set windowBits to 9 replicating the legacy behavior to avoid a DOS vector. nodejs-private/node-private#95 PR-URL: nodejs-private/node-private#98
Make
--expose-http2
a non-op,Expose http2 by default.
Add
NODE_NO_HTTP2=1
to suppress http2Note that this flips the default in v8.x, turning http2 always on. For anyone currently using the http2 userland module, they would need to set the
NODE_NO_HTTP2=1
environment variable to avoid breaking.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
http2