[v11.x backport] http: reduce usage of public util

.eslintrc.js

@@ -60,9 +60,9 @@ module.exports = {
     'brace-style': ['error', '1tbs', { allowSingleLine: true }],
     'capitalized-comments': ['error', 'always', {
       line: {
-        // Ignore all lines that have less characters than 40 and all lines that
+        // Ignore all lines that have less characters than 30 and all lines that
         // start with something that looks like a variable name or code.
-        ignorePattern: '^.{0,40}$|^ [a-z]+ ?[0-9A-Z_.(/=:[#-]|^ std',
+        ignorePattern: '^.{0,30}$|^ [a-z]+ ?[0-9A-Z_.(/=:[#-]|^ std',
         ignoreInlineComments: true,
         ignoreConsecutiveComments: true,
       },

BUILDING.md

@@ -72,7 +72,7 @@ There are three support tiers:
 For production applications, run Node.js on supported platforms only.
 
 Node.js does not support a platform version if a vendor has expired support
-for it. In other words, Node.js does not support running on End-of-life (EoL)
+for it. In other words, Node.js does not support running on End-of-Life (EoL)
 platforms. This is true regardless of entries in the table below.
 
 | System       | Support type | Version                         | Architectures    | Notes                         |

COLLABORATOR_GUIDE.md

@@ -305,7 +305,6 @@ in the placeholder's `README`.
 For pull requests introducing new core modules:
 
 * Allow at least one week for review.
-* Label with the `tsc-review` label.
 * Land only after sign-off from at least two TSC members.
 * Land with a [Stability Index][] of Experimental. The module must remain
   Experimental until a semver-major release.
@@ -334,7 +333,7 @@ documentation must state the deprecation status.
   * Emits a warning at runtime on first use of the deprecated API.
   * If used with the [`--throw-deprecation`][] flag, will throw a runtime error.
 
-* End-of-life
+* End-of-Life
   * The API is no longer subject to the semantic versioning rules.
   * Backward-incompatible changes including complete removal of such APIs may
     occur at any time.
@@ -343,89 +342,85 @@ Apply the `notable change` label to all pull requests that introduce
 Documentation-Only Deprecations. Such deprecations have no impact on code
 execution. Thus, they are not breaking changes (`semver-major`).
 
-Runtime Deprecations and End-of-life APIs (internal or public) are breaking
+Runtime Deprecations and End-of-Life APIs (internal or public) are breaking
 changes (`semver-major`). The TSC may make exceptions, deciding that one of
 these deprecations is not a breaking change.
 
 All deprecations receive a unique and immutable identifier. Documentation,
 warnings, and errors use the identifier when referring to the deprecation. The
-documentation for the assigned deprecation identifier must always remain in the
-API documentation. This is true even if the deprecation is no longer in use (for
+documentation for the deprecation identifier must always remain in the API
+documentation. This is true even if the deprecation is no longer in use (for
 example, due to removal of an End-of-Life deprecated API).
 
 <a id="deprecation-cycle"></a>
-A _Deprecation cycle_ is a major release during which an API has been in one of
+A _deprecation cycle_ is a major release during which an API has been in one of
 the three Deprecation levels. Documentation-Only Deprecations may land in a
-minor release but must not be upgraded to a Runtime Deprecation until the next
-major release.
+minor release. They may not change to a Runtime Deprecation until the next major
+release.
 
-No API can be moved to End-of-life without first having gone through a
-Runtime Deprecation cycle. However, there is no requirement that deprecated
-code must progress ultimately to *End-of-Life*. Documentation-only and runtime
-deprecations may remain indefinitely.
+No API can change to End-of-Life without going through a Runtime Deprecation
+cycle. There is no rule that deprecated code must progress to End-of-Life.
+Documentation-Only and Runtime Deprecations may remain in place for an unlimited
+duration.
 
 Communicate pending deprecations and associated mitigations with the ecosystem
-as soon as possible (preferably before the pull request adding the deprecation
-lands on the master branch). Use the `notable-change` label on all pull requests
-that add a new deprecation or move an existing deprecation to a new deprecation
-level.
+as soon as possible. If possible, do it before the pull request adding the
+deprecation lands on the master branch.
+
+Use the `notable-change` label on pull requests that add or change the
+deprecation level of an API.
 
 ### Involving the TSC
 
 Collaborators may opt to elevate pull requests or issues to the [TSC][].
-This should be done where a pull request:
+Do this if a pull request or issue:
 
 - is labeled `semver-major`, or
 - has a significant impact on the codebase, or
-- is inherently controversial, or
-- has failed to reach consensus amongst the Collaborators who are
-  actively participating in the discussion.
+- is controversial, or
+- is at an impasse among Collaborators who are participating in the discussion.
 
-Assign the `tsc-review` label or @-mention the
-`@nodejs/tsc` GitHub team if you want to elevate an issue to the [TSC][].
-Do not use the GitHub UI on the right-hand side to assign to
+@-mention the `@nodejs/tsc` GitHub team if you want to elevate an issue to the
+[TSC][]. Do not use the GitHub UI on the right-hand side to assign to
 `@nodejs/tsc` or request a review from `@nodejs/tsc`.
 
 The TSC should serve as the final arbiter where required.
 
 ## Landing Pull Requests
 
-1. Avoid landing PRs that are assigned to someone else. Authors who wish to land
-   their own PRs will self-assign them, or delegate to someone else. If in
-   doubt, ask the assignee whether it is okay to land.
+1. Avoid landing pull requests that have someone else as an assignee. Authors
+   who wish to land their own pull requests will self-assign them. Sometimes, an
+   author will delegate to someone else. If in doubt, ask the assignee whether
+   it is okay to land.
 1. Never use GitHub's green ["Merge Pull Request"][] button. Reasons for not
    using the web interface button:
    * The "Create a merge commit" method will add an unnecessary merge commit.
-   * The "Squash and merge" method will add metadata (the PR #) to the commit
-     title. If more than one author has contributed to the PR, squashing will
-     only keep the most recent author.
+   * The "Squash and merge" method will add metadata (the pull request #) to the
+     commit title. If more than one author contributes to the pull request,
+     squashing only keeps one author.
    * The "Rebase and merge" method has no way of adding metadata to the commit.
-1. Make sure the CI is done and the result is green. If the CI is not green,
-   check for flaky tests and infrastructure failures. Please check if those were
-   already reported in the appropriate repository ([node][flaky tests] and
-   [build](https://github.com/nodejs/build/issues)) or not and open new issues
-   in case they are not. If no CI was run or the run is outdated because code
-   was pushed after the last run, please first start a new CI and wait for the
-   result. If no CI is required, please leave a comment in case none is already
-   present.
-1. Review the commit message to ensure that it adheres to the guidelines
-   outlined in the [contributing][] guide.
+1. Make sure CI is complete and green. If the CI is not green, check for
+   unreliable tests and infrastructure failures. If there are not corresponding
+   issues in the [node][unreliable tests] or
+   [build](https://github.com/nodejs/build/issues) repositories, open new
+   issues. Run a new CI any time someone pushes new code to the pull request.
+1. Check that the commit message adheres to [commit message guidelines][].
 1. Add all necessary [metadata](#metadata) to commit messages before landing. If
    you are unsure exactly how to format the commit messages, use the commit log
    as a reference. See [this commit][commit-example] as an example.
 
-For PRs from first-time contributors, be [welcoming](#welcoming-first-time-contributors).
-Also, verify that their git settings are to their liking.
+For pull requests from first-time contributors, be
+[welcoming](#welcoming-first-time-contributors). Also, verify that their git
+settings are to their liking.
 
 All commits should be self-contained, meaning every commit should pass all
 tests. This makes it much easier when bisecting to find a breaking change.
 
 ### Using `git-node`
 
 In most cases, using [the `git-node` command][git-node] of [`node-core-utils`][]
-should be enough to help you land a Pull Request. If you discover a problem when
-using this tool, please file an issue
-[to the issue tracker][node-core-utils-issues].
+should be enough to land a pull request. If you discover a problem when using
+this tool, please file an issue [to the issue tracker][node-core-utils-issues].
 
 Quick example:
 
@@ -434,12 +429,11 @@ $ npm install -g node-core-utils
 $ git node land $PRID
 ```
 
-If it's the first time you have used `node-core-utils`, you will be prompted
-to type the password of your GitHub account and the two-factor authentication
-code in the console so the tool can create the GitHub access token for you.
-If you do not want to do that, follow
-[the `node-core-utils` guide][node-core-utils-credentials]
-to set up your credentials manually.
+To use `node-core-utils`, you will need a GitHub access token. If you do not
+have one, `node-core-utils` will create one for you the first time you use it.
+To do this, it will ask for your GitHub password and two-factor authentication
+code. If you wish to create the token yourself in advance, see
+[the `node-core-utils` guide][node-core-utils-credentials].
 
 ### Technical HOWTO
 
@@ -552,8 +546,7 @@ commit message for that commit. This is a good moment to fix incorrect
 commit logs, ensure that they are properly formatted, and add
 `Reviewed-By` lines.
 
-* The commit message text must conform to the
-[commit message guidelines](./doc/guides/contributing/pull-requests.md#commit-message-guidelines).
+* The commit message text must conform to the [commit message guidelines][].
 
 <a name="metadata"></a>
 * Modify the original commit message to include additional metadata regarding
@@ -795,12 +788,12 @@ If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help.
 [`--throw-deprecation`]: doc/api/cli.md#--throw-deprecation
 [`node-core-utils`]: https://github.com/nodejs/node-core-utils
 [backporting guide]: doc/guides/backporting-to-release-lines.md
-[contributing]: ./doc/guides/contributing/pull-requests.md#commit-message-guidelines
+[commit message guidelines]: ./doc/guides/contributing/pull-requests.md#commit-message-guidelines
 [commit-example]: https://github.com/nodejs/node/commit/b636ba8186
-[flaky tests]: https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3A%22CI+%2F+flaky+test%22y
 [git-node]: https://github.com/nodejs/node-core-utils/blob/master/docs/git-node.md
 [git-node-metadata]: https://github.com/nodejs/node-core-utils/blob/master/docs/git-node.md#git-node-metadata
 [git-username]: https://help.github.com/articles/setting-your-username-in-git/
 [git-email]: https://help.github.com/articles/setting-your-commit-email-address-in-git/
 [node-core-utils-credentials]: https://github.com/nodejs/node-core-utils#setting-up-credentials
 [node-core-utils-issues]: https://github.com/nodejs/node-core-utils/issues
+[unreliable tests]: https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3A%22CI+%2F+flaky+test%22

GOVERNANCE.md

@@ -50,10 +50,6 @@ be accepted unless:
   This should only happen if disagreements between Collaborators cannot be
   resolved through discussion.
 
-Collaborators may opt to elevate significant or controversial modifications to
-the TSC by assigning the `tsc-review` label to a pull request or issue. The
-TSC should serve as the final arbiter where required.
-
 See:
 
 * [Current list of Collaborators](./README.md#current-project-team-members)
@@ -105,11 +101,9 @@ The intention of the agenda is not to approve or review all patches.
 That should happen continuously on GitHub and be handled by the larger
 group of Collaborators.
 
-Any community member or contributor can ask that something be reviewed
-by the TSC by logging a GitHub issue. Any Collaborator, TSC member, or the
-meeting chair can bring the issue to the TSC's attention by applying the
-`tsc-review` label. If consensus-seeking among TSC members fails for a
-particular issue, it may be added to the TSC meeting agenda by adding the
+Any community member or contributor can ask that something be reviewed by the
+TSC by logging a GitHub issue. If consensus-seeking among TSC members fails for
+a particular issue, it may be added to the TSC meeting agenda by adding the
 `tsc-agenda` label.
 
 Prior to each TSC meeting, the meeting chair will share the agenda with

LICENSE

@@ -774,6 +774,17 @@ The externally maintained libraries used by Node.js are:
     OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   """
 
+- SipHash, located at deps/v8/src/third_party/siphash, is licensed as follows:
+  """
+    SipHash reference C implementation
+
+    Copyright (c) 2016 Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
+
+    To the extent possible under law, the author(s) have dedicated all
+    copyright and related and neighboring rights to this software to the public
+    domain worldwide. This software is distributed without any warranty.
+  """
+
 - zlib, located at deps/zlib, is licensed as follows:
   """
     zlib.h -- interface of the 'zlib' general purpose compression library

Makefile

@@ -1266,8 +1266,11 @@ else
 	@echo "To install (requires internet access) run: $ make format-cpp-build"
 endif
 
-CPPLINT_QUIET = --quiet
-
+ifeq ($(V),1)
+  CPPLINT_QUIET =
+else
+  CPPLINT_QUIET = --quiet
+endif
 .PHONY: lint-cpp
 # Lints the C++ code with cpplint.py and check-imports.py.
 lint-cpp: tools/.cpplintstamp

benchmark/_cli.js

@@ -65,7 +65,7 @@ function CLI(usage, settings) {
       // item arguments
       this.items.push(arg);
 
-      // the next value must be an item
+      // The next value must be an item
       mode = 'item';
     } else {
       // Bad case, abort

benchmark/net/net-c2s-cork.js

@@ -1,4 +1,4 @@
-// test the speed of .pipe() with sockets
+// Test the speed of .pipe() with sockets
 'use strict';
 
 const common = require('../common.js');
@@ -78,7 +78,7 @@ Writer.prototype.write = function(chunk, encoding, cb) {
   return true;
 };
 
-// doesn't matter, never emits anything.
+// Doesn't matter, never emits anything.
 Writer.prototype.on = function() {};
 Writer.prototype.once = function() {};
 Writer.prototype.emit = function() {};

benchmark/net/net-c2s.js

@@ -1,4 +1,4 @@
-// test the speed of .pipe() with sockets
+// Test the speed of .pipe() with sockets
 'use strict';
 
 const common = require('../common.js');
@@ -72,7 +72,7 @@ Writer.prototype.write = function(chunk, encoding, cb) {
   return true;
 };
 
-// doesn't matter, never emits anything.
+// Doesn't matter, never emits anything.
 Writer.prototype.on = function() {};
 Writer.prototype.once = function() {};
 Writer.prototype.emit = function() {};

benchmark/net/net-pipe.js

@@ -1,4 +1,4 @@
-// test the speed of .pipe() with sockets
+// Test the speed of .pipe() with sockets
 'use strict';
 
 const common = require('../common.js');
@@ -75,7 +75,7 @@ Writer.prototype.write = function(chunk, encoding, cb) {
   return true;
 };
 
-// doesn't matter, never emits anything.
+// Doesn't matter, never emits anything.
 Writer.prototype.on = function() {};
 Writer.prototype.once = function() {};
 Writer.prototype.emit = function() {};

benchmark/net/net-s2c.js

@@ -1,4 +1,4 @@
-// test the speed of .pipe() with sockets
+// Test the speed of .pipe() with sockets
 'use strict';
 
 const common = require('../common.js');
@@ -73,7 +73,7 @@ Writer.prototype.write = function(chunk, encoding, cb) {
   return true;
 };
 
-// doesn't matter, never emits anything.
+// Doesn't matter, never emits anything.
 Writer.prototype.on = function() {};
 Writer.prototype.once = function() {};
 Writer.prototype.emit = function() {};

benchmark/net/net-wrap-js-stream-passthrough.js

@@ -68,7 +68,7 @@ Writer.prototype.write = function(chunk, encoding, cb) {
   return true;
 };
 
-// doesn't matter, never emits anything.
+// Doesn't matter, never emits anything.
 Writer.prototype.on = function() {};
 Writer.prototype.once = function() {};
 Writer.prototype.emit = function() {};

benchmark/net/tcp-raw-s2c.js

@@ -5,9 +5,9 @@
 const common = require('../common.js');
 const util = require('util');
 
-// if there are dur=N and len=N args, then
+// If there are dur=N and len=N args, then
 // run the function with those settings.
-// if not, then queue up a bunch of child processes.
+// If not, then queue up a bunch of child processes.
 const bench = common.createBenchmark(main, {
   len: [102400, 1024 * 1024 * 16],
   type: ['utf', 'asc', 'buf'],

benchmark/run.js

@@ -50,7 +50,7 @@ if (format === 'csv') {
     for (const key of Object.keys(data.conf)) {
       conf += ` ${key}=${JSON.stringify(data.conf[key])}`;
     }
-    // delete first space of the configuration
+    // Delete first space of the configuration
     conf = conf.slice(1);
     if (format === 'csv') {
       // Escape quotes (") for correct csv formatting

benchmark/timers/immediate.js

@@ -57,7 +57,7 @@ function depth1(N) {
   }
 }
 
-// concurrent setImmediate, 0 arguments
+// Concurrent setImmediate, 0 arguments
 function breadth(N) {
   var n = 0;
   bench.start();
@@ -71,7 +71,7 @@ function breadth(N) {
   }
 }
 
-// concurrent setImmediate, 1 argument
+// Concurrent setImmediate, 1 argument
 function breadth1(N) {
   var n = 0;
   bench.start();
@@ -85,7 +85,7 @@ function breadth1(N) {
   }
 }
 
-// concurrent setImmediate, 4 arguments
+// Concurrent setImmediate, 4 arguments
 function breadth4(N) {
   N /= 2;
   var n = 0;