meta: merge node/master into node-chakracore/master

Merge 47a984a as of 2018-02-04
This commit was automatically generated. For any problems, please contact jackhorton

Reviewed-By: chakrabot <chakrabot@users.noreply.github.com>

Author: chakrabot

benchmark/tls/throughput.js

@@ -40,11 +40,11 @@ function main({ dur, type, size }) {
   };
 
   server = tls.createServer(options, onConnection);
-  setTimeout(done, dur * 1000);
   var conn;
   server.listen(common.PORT, function() {
     const opt = { port: common.PORT, rejectUnauthorized: false };
     conn = tls.connect(opt, function() {
+      setTimeout(done, dur * 1000);
       bench.start();
       conn.on('drain', write);
       write();

configure

@@ -61,7 +61,7 @@ parser = optparse.OptionParser()
 valid_os = ('win', 'mac', 'solaris', 'freebsd', 'openbsd', 'linux',
             'android', 'aix', 'cloudabi')
 valid_arch = ('arm', 'arm64', 'ia32', 'mips', 'mipsel', 'mips64el', 'ppc',
-              'ppc64', 'x32','x64', 'x86', 's390', 's390x')
+              'ppc64', 'x32','x64', 'x86', 'x86_64', 's390', 's390x')
 valid_arm_float_abi = ('soft', 'softfp', 'hard')
 valid_arm_fpu = ('vfp', 'vfpv3', 'vfpv3-d16', 'neon')
 valid_mips_arch = ('loongson', 'r1', 'r2', 'r6', 'rx')
@@ -891,6 +891,9 @@ def configure_node(o):
   # the Makefile resets this to x86 afterward
   if target_arch == 'x86':
     target_arch = 'ia32'
+  # x86_64 is common across linuxes, allow it as an alias for x64
+  if target_arch == 'x86_64':
+    target_arch = 'x64'
   o['variables']['host_arch'] = host_arch
   o['variables']['target_arch'] = target_arch
   o['variables']['node_byteorder'] = sys.byteorder

doc/api/child_process.md

@@ -44,7 +44,7 @@ implemented on top of [`child_process.spawn()`][] or [`child_process.spawnSync()
   * [`child_process.exec()`][]: spawns a shell and runs a command within that shell,
     passing the `stdout` and `stderr` to a callback function when complete.
   * [`child_process.execFile()`][]: similar to [`child_process.exec()`][] except that
-    it spawns the command directly without first spawning a shell.
+    it spawns the command directly without first spawning a shell by default.
   * [`child_process.fork()`][]: spawns a new Node.js process and invokes a
     specified module with an IPC communication channel established that allows
     sending messages between parent and child.
@@ -78,7 +78,7 @@ when the child process terminates.
 The importance of the distinction between [`child_process.exec()`][] and
 [`child_process.execFile()`][] can vary based on platform. On Unix-type operating
 systems (Unix, Linux, macOS) [`child_process.execFile()`][] can be more efficient
-because it does not spawn a shell. On Windows, however, `.bat` and `.cmd`
+because it does not spawn a shell by default. On Windows, however, `.bat` and `.cmd`
 files are not executable on their own without a terminal, and therefore cannot
 be launched using [`child_process.execFile()`][]. When running on Windows, `.bat`
 and `.cmd` files can be invoked using [`child_process.spawn()`][] with the `shell`
@@ -266,14 +266,18 @@ changes:
     normally be created on Windows systems. **Default:** `false`.
   * `windowsVerbatimArguments` {boolean} No quoting or escaping of arguments is
     done on Windows. Ignored on Unix. **Default:** `false`.
+  * `shell` {boolean|string} If `true`, runs `command` inside of a shell. Uses
+    `'/bin/sh'` on UNIX, and `process.env.ComSpec` on Windows. A different
+    shell can be specified as a string. See [Shell Requirements][] and
+    [Default Windows Shell][]. **Default:** `false` (no shell).
 * `callback` {Function} Called with the output when process terminates.
   * `error` {Error}
   * `stdout` {string|Buffer}
   * `stderr` {string|Buffer}
 * Returns: {ChildProcess}
 
 The `child_process.execFile()` function is similar to [`child_process.exec()`][]
-except that it does not spawn a shell. Rather, the specified executable `file`
+except that it does not spawn a shell by default. Rather, the specified executable `file`
 is spawned directly as a new process making it slightly more efficient than
 [`child_process.exec()`][].
 
@@ -312,6 +316,10 @@ async function getVersion() {
 getVersion();
 ```
 
+*Note*: If the `shell` option is enabled, do not pass unsanitized user input
+to this function. Any input containing shell metacharacters may be used to
+trigger arbitrary command execution.
+
 ### child_process.fork(modulePath[, args][, options])
 <!-- YAML
 added: v0.5.0
@@ -705,6 +713,10 @@ changes:
   * `encoding` {string} The encoding used for all stdio inputs and outputs. **Default:** `'buffer'`
   * `windowsHide` {boolean} Hide the subprocess console window that would
     normally be created on Windows systems. **Default:** `false`.
+  * `shell` {boolean|string} If `true`, runs `command` inside of a shell. Uses
+    `'/bin/sh'` on UNIX, and `process.env.ComSpec` on Windows. A different
+    shell can be specified as a string. See [Shell Requirements][] and
+    [Default Windows Shell][]. **Default:** `false` (no shell).
 * Returns: {Buffer|string} The stdout from the command.
 
 The `child_process.execFileSync()` method is generally identical to
@@ -721,6 +733,10 @@ If the process times out or has a non-zero exit code, this method ***will***
 throw an [`Error`][] that will include the full result of the underlying
 [`child_process.spawnSync()`][].
 
+*Note*: If the `shell` option is enabled, do not pass unsanitized user input
+to this function. Any input containing shell metacharacters may be used to
+trigger arbitrary command execution.
+
 ### child_process.execSync(command[, options])
 <!-- YAML
 added: v0.11.12

doc/api/http.md

@@ -1878,6 +1878,49 @@ const req = http.request(options, (res) => {
 });
 ```
 
+In a successful request, the following events will be emitted in the following
+order:
+
+* `socket`
+* `response`
+  * `data` any number of times, on the `res` object
+    (`data` will not be emitted at all if the response body is empty, for
+    instance, in most redirects)
+  * `end` on the `res` object
+* `close`
+
+In the case of a connection error, the following events will be emitted:
+
+* `socket`
+* `error`
+* `close`
+
+If `req.abort()` is called before the connection succeeds, the following events
+will be emitted in the following order:
+
+* `socket`
+* (`req.abort()` called here)
+* `abort`
+* `close`
+* `error` with an error with message `Error: socket hang up` and code
+  `ECONNRESET`
+
+If `req.abort()` is called after the response is received, the following events
+will be emitted in the following order:
+
+* `socket`
+* `response`
+  * `data` any number of times, on the `res` object
+* (`req.abort()` called here)
+* `abort`
+* `close`
+  * `aborted` on the `res` object
+  * `end` on the `res` object
+  * `close` on the `res` object
+
+Note that setting the `timeout` option or using the `setTimeout` function will
+not abort the request or do anything besides add a `timeout` event.
+
 [`'checkContinue'`]: #http_event_checkcontinue
 [`'request'`]: #http_event_request
 [`'response'`]: #http_event_response

doc/api/http2.md

@@ -19,8 +19,8 @@ compatibility with the existing [HTTP/1][] module API. However,
 the [Compatibility API][] is.
 
 The `http2` Core API is much more symmetric between client and server than the
-`http` API. For instance, most events, like `error` and `socketError`, can be
-emitted either by client-side code or server-side code.
+`http` API. For instance, most events, like `error`, `connect` and `stream`, can
+be emitted either by client-side code or server-side code.
 
 ### Server-side example
 
@@ -36,7 +36,6 @@ const server = http2.createSecureServer({
   cert: fs.readFileSync('localhost-cert.pem')
 });
 server.on('error', (err) => console.error(err));
-server.on('socketError', (err) => console.error(err));
 
 server.on('stream', (stream, headers) => {
   // stream is a Duplex
@@ -68,7 +67,6 @@ const client = http2.connect('https://localhost:8443', {
   ca: fs.readFileSync('localhost-cert.pem')
 });
 client.on('error', (err) => console.error(err));
-client.on('socketError', (err) => console.error(err));
 
 const req = client.request({ ':path': '/' });
 
@@ -479,44 +477,6 @@ Used to set a callback function that is called when there is no activity on
 the `Http2Session` after `msecs` milliseconds. The given `callback` is
 registered as a listener on the `'timeout'` event.
 
-#### http2session.close(options[, callback])
-<!-- YAML
-added: v8.4.0
--->
-
-* `options` {Object}
-  * `errorCode` {number} The HTTP/2 [error code][] to return. Note that this is
-    *not* the same thing as an HTTP Response Status Code. **Default:** `0x00`
-    (No Error).
-  * `lastStreamID` {number} The Stream ID of the last successfully processed
-    `Http2Stream` on this `Http2Session`. If unspecified, will default to the
-    ID of the most recently received stream.
-  * `opaqueData` {Buffer|Uint8Array} A `Buffer` or `Uint8Array` instance
-    containing arbitrary additional data to send to the peer upon disconnection.
-    This is used, typically, to provide additional data for debugging failures,
-    if necessary.
-* `callback` {Function} A callback that is invoked after the session shutdown
-  has been completed.
-* Returns: {undefined}
-
-Attempts to shut down this `Http2Session` using HTTP/2 defined procedures.
-If specified, the given `callback` function will be invoked once the shutdown
-process has completed.
-
-If the `Http2Session` instance is a server-side session and the `errorCode`
-option is `0x00` (No Error), a "graceful" shutdown will be initiated. During a
-"graceful" shutdown, the session will first send a `GOAWAY` frame to
-the connected peer identifying the last processed stream as 2<sup>31</sup>-1.
-Then, on the next tick of the event loop, a second `GOAWAY` frame identifying
-the most recently processed stream identifier is sent. This process allows the
-remote peer to begin preparing for the connection to be terminated.
-
-```js
-session.close({
-  opaqueData: Buffer.from('add some debugging data here')
-}, () => session.destroy());
-```
-
 #### http2session.socket
 <!-- YAML
 added: v8.4.0
@@ -686,19 +646,23 @@ added: v8.4.0
 added: v9.4.0
 -->
 
+* `alt`: {string}
+* `origin`: {string}
+* `streamId`: {number}
+
 The `'altsvc'` event is emitted whenever an `ALTSVC` frame is received by
 the client. The event is emitted with the `ALTSVC` value, origin, and stream
-ID, if any. If no `origin` is provided in the `ALTSVC` frame, `origin` will
+ID. If no `origin` is provided in the `ALTSVC` frame, `origin` will
 be an empty string.
 
 ```js
 const http2 = require('http2');
 const client = http2.connect('https://example.org');
 
-client.on('altsvc', (alt, origin, stream) => {
+client.on('altsvc', (alt, origin, streamId) => {
   console.log(alt);
   console.log(origin);
-  console.log(stream);
+  console.log(streamId);
 });
 ```
 
@@ -1472,10 +1436,9 @@ added: v8.4.0
 
 * Extends: {net.Server}
 
-In `Http2Server`, there is no `'clientError'` event as there is in
-HTTP1. However, there are `'socketError'`, `'sessionError'`,  and
-`'streamError'`, for errors emitted on the socket, `Http2Session`, or
-`Http2Stream`.
+In `Http2Server`, there are no `'clientError'` events as there are in
+HTTP1. However, there are `'sessionError'`,  and `'streamError'` events for
+errors emitted on the socket, or from `Http2Session` or `Http2Stream` instances.
 
 #### Event: 'checkContinue'
 <!-- YAML
@@ -1580,23 +1543,54 @@ added: v8.4.0
 
 * Extends: {tls.Server}
 
-#### Event: 'sessionError'
+#### Event: 'checkContinue'
+<!-- YAML
+added: v8.5.0
+-->
+
+* `request` {http2.Http2ServerRequest}
+* `response` {http2.Http2ServerResponse}
+
+If a [`'request'`][] listener is registered or [`http2.createSecureServer()`][]
+is supplied a callback function, the `'checkContinue'` event is emitted each
+time a request with an HTTP `Expect: 100-continue` is received. If this event
+is not listened for, the server will automatically respond with a status
+`100 Continue` as appropriate.
+
+Handling this event involves calling [`response.writeContinue()`][] if the client
+should continue to send the request body, or generating an appropriate HTTP
+response (e.g. 400 Bad Request) if the client should not continue to send the
+request body.
+
+Note that when this event is emitted and handled, the [`'request'`][] event will
+not be emitted.
+
+#### Event: 'request'
 <!-- YAML
 added: v8.4.0
 -->
 
-The `'sessionError'` event is emitted when an `'error'` event is emitted by
-an `Http2Session` object associated with the `Http2SecureServer`.
+* `request` {http2.Http2ServerRequest}
+* `response` {http2.Http2ServerResponse}
 
-#### Event: 'unknownProtocol'
+Emitted each time there is a request. Note that there may be multiple requests
+per session. See the [Compatibility API][].
+
+#### Event: 'session'
 <!-- YAML
 added: v8.4.0
 -->
 
-The `'unknownProtocol'` event is emitted when a connecting client fails to
-negotiate an allowed protocol (i.e. HTTP/2 or HTTP/1.1). The event handler
-receives the socket for handling. If no listener is registered for this event,
-the connection is terminated. See the [Compatibility API][].
+The `'session'` event is emitted when a new `Http2Session` is created by the
+`Http2SecureServer`.
+
+#### Event: 'sessionError'
+<!-- YAML
+added: v8.4.0
+-->
+
+The `'sessionError'` event is emitted when an `'error'` event is emitted by
+an `Http2Session` object associated with the `Http2SecureServer`.
 
 #### Event: 'stream'
 <!-- YAML
@@ -1631,43 +1625,23 @@ server.on('stream', (stream, headers, flags) => {
 });
 ```
 
-#### Event: 'request'
+#### Event: 'timeout'
 <!-- YAML
 added: v8.4.0
 -->
 
-* `request` {http2.Http2ServerRequest}
-* `response` {http2.Http2ServerResponse}
-
-Emitted each time there is a request. Note that there may be multiple requests
-per session. See the [Compatibility API][].
+The `'timeout'` event is emitted when there is no activity on the Server for
+a given number of milliseconds set using `http2secureServer.setTimeout()`.
 
-#### Event: 'timeout'
+#### Event: 'unknownProtocol'
 <!-- YAML
 added: v8.4.0
 -->
 
-#### Event: 'checkContinue'
-<!-- YAML
-added: v8.5.0
--->
-
-* `request` {http2.Http2ServerRequest}
-* `response` {http2.Http2ServerResponse}
-
-If a [`'request'`][] listener is registered or [`http2.createSecureServer()`][]
-is supplied a callback function, the `'checkContinue'` event is emitted each
-time a request with an HTTP `Expect: 100-continue` is received. If this event
-is not listened for, the server will automatically respond with a status
-`100 Continue` as appropriate.
-
-Handling this event involves calling [`response.writeContinue()`][] if the client
-should continue to send the request body, or generating an appropriate HTTP
-response (e.g. 400 Bad Request) if the client should not continue to send the
-request body.
-
-Note that when this event is emitted and handled, the [`'request'`][] event will
-not be emitted.
+The `'unknownProtocol'` event is emitted when a connecting client fails to
+negotiate an allowed protocol (i.e. HTTP/2 or HTTP/1.1). The event handler
+receives the socket for handling. If no listener is registered for this event,
+the connection is terminated. See the [Compatibility API][].
 
 ### http2.createServer(options[, onRequestHandler])
 <!-- YAML