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

[8.x] http2: expose http2 by default, add NODE_NO_HTTP2 #15685

Closed
wants to merge 2 commits into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Sep 29, 2017

Make --expose-http2 a non-op,
Expose http2 by default.
Add NODE_NO_HTTP2=1 to suppress http2

Note 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), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

http2

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. v8.x labels Sep 29, 2017
@jasnell
Copy link
Member Author

jasnell commented Sep 29, 2017

/cc @ofrobots @MylesBorins @mcollina @nodejs/http2 @nodejs/lts

@mcollina
Copy link
Member

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?

@jasnell
Copy link
Member Author

jasnell commented Sep 29, 2017

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 :-)

@sam-github
Copy link
Contributor

I know its really late in the game to bring up things like this.... but wasrequire('http/2') considered as a name? It would have side-stepped the name conflict problem.

Copy link
Contributor

@MylesBorins MylesBorins left a 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.
Copy link
Contributor

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

Copy link
Contributor

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
//
Copy link
Contributor

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
Copy link
Contributor

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

Copy link
Member Author

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 :-)

@nwgh
Copy link

nwgh commented Sep 29, 2017

@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).

Copy link
Contributor

@refack refack left a 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.
Copy link
Contributor

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

@refack
Copy link
Contributor

refack commented Sep 29, 2017

General context:
Is this a precedent (introducing an interim runtime switch)? Can we formalize and document, so if a similar situation arises we'll be consistant.
There is a similar discussion in #15454 around adding --force-async-hooks-checks just for the v8.x LTS.

@@ -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.
Copy link
Member

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');
Copy link
Member

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"?

@MylesBorins
Copy link
Contributor

@jasnell would you be able to rebase?

@nodejs/tsc @nodejs/release can you please chime in

@mhdawson
Copy link
Member

mhdawson commented Oct 3, 2017

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.

@sam-github
Copy link
Contributor

Is it worth considering http/2 as the module name? Its still experimental, so we can change the name.

http/2 seems just as good a name as http2, and it completely sidesteps the name conflict problem and possibly semver-majorness. Would make it easier to backport, I'd think, into LTS.

@jasnell
Copy link
Member Author

jasnell commented Oct 3, 2017

@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 http2, renaming it at this point is unnecessarily disruptive.

@sam-github
Copy link
Contributor

sam-github commented Oct 5, 2017

If http2 is exposed by default, then it masks the http2 installed from npmjs.org, so people using the package version won't be able to upgrade across this, not without changing the environment, right? Technically, this sounds semver-major to me.

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 http2 is proposed for backport, it will (EDIT: probably) have to be hidden behind a flag in 6.x, and at least some users find depending on features hidden behind CLI flags to be incredibly onerous.

And of course, existing (EDIT: http2) users are using an API that has absolutely no stability guarantee, removal of the API is explicitly allowed.

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

@joyeecheung
Copy link
Member

joyeecheung commented Oct 5, 2017

@jasnell @sam-github @nwgh Just noticed that the engines field of the http2 module is ">=0.12.0 <9.0.0" ( https://github.com/molnarg/node-http2/blob/v3.3.7/package.json ) so it still can be installed in 8.x (and the <9.0.0 part was only added in v3.3.7), I think for this PR to land we should at least get that field changed to <8.0.0? (If @nwgh is OK with it at least)

@sam-github
Copy link
Contributor

engines is advisory (https://docs.npmjs.com/files/package.json#engines), but would be good to have set. It shouldn't be <8.0.0 though, I don't think, but less than the specific release number where http2 is exposed by default.

@nwgh
Copy link

nwgh commented Oct 8, 2017

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 :)

@Fishrock123
Copy link
Contributor

From the discussion in the TSC meeting (nodejs/TSC#384) this seems reasonable to me.

@jasnell
Copy link
Member Author

jasnell commented Oct 18, 2017

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
@jasnell
Copy link
Member Author

jasnell commented Oct 18, 2017

This is rebased.

@jasnell
Copy link
Member Author

jasnell commented Oct 18, 2017

evanlucas pushed a commit that referenced this pull request Oct 23, 2017
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 <myles.borins@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
evanlucas pushed a commit that referenced this pull request Oct 23, 2017
Remove the --expose-http2 flag from tests and benchmarks

PR-URL: #15685
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
@evanlucas
Copy link
Contributor

Landed in 57ab6e2 and e01daec. Thanks!

@evanlucas evanlucas closed this Oct 23, 2017
@evanlucas evanlucas added the semver-minor PRs that contain new features and should be released in the next minor version. label Oct 23, 2017
@MylesBorins
Copy link
Contributor

@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?

@MylesBorins
Copy link
Contributor

building on the last message. I currently have intent to ship http2 without a flag tomorrow. Opening a new issue

MylesBorins added a commit that referenced this pull request Oct 24, 2017
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
addaleax pushed a commit to ayojs/ayo that referenced this pull request Oct 26, 2017
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
@mgibson1187
Copy link

mgibson1187 commented Oct 26, 2017

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

gibfahn added a commit to gibfahn/node that referenced this pull request Oct 31, 2017
I assume they aren't meant to be there.

Refs: nodejs#15685
MylesBorins pushed a commit that referenced this pull request Oct 31, 2017
I assume they aren't meant to be there.

PR-URL: #16631
Refs: #15685
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@refack
Copy link
Contributor

refack commented Nov 4, 2017

@mgibson1187 was your issue resolved? Did you try the webpack repo (https://github.com/webpack/webpack/issues)?

addaleax pushed a commit to ayojs/ayo that referenced this pull request Dec 7, 2017
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. semver-minor PRs that contain new features and should be released in the next minor version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.