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

fs: Add file descriptor support to *File() funcs #3163

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
6 participants
@jwueller
Contributor

jwueller commented Oct 3, 2015

This is a re-targeted submission of the archived PR #8522, implementing the archived issue #8471.

The original description follows.


These changes affect the following functions and their synchronous counterparts:

  • fs.readFile()
  • fs.writeFile()
  • fs.appendFile()

If the first parameter is a uint32, it is treated as a file descriptor. In all other cases, the original implementation is used to ensure backwards compatibility. File descriptor ownership is never taken from the user.

The documentation was adjusted to reflect these API changes. A note was added to make the user aware of file descriptor ownership and the conditions under which a file descriptor can be used by each of these functions.

Tests were extended to test for file descriptor parameters under the conditions noted in the relevant documentation.

@mscdex mscdex added the fs label Oct 3, 2015

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 3, 2015

/cc @trevnorris @misterdjules

This one also includes a test for fs.writeFileSync(), where the original PR did not.

@ChALkeR ChALkeR added the semver-minor label Oct 4, 2015

@ChALkeR

View changes

lib/fs.js Outdated
@@ -101,6 +101,10 @@ function nullCheck(path, callback) {
return true;
}
function isFd(path) {
return (path >>> 0) === path && path >= 0;

This comment has been minimized.

@ChALkeR

ChALkeR Oct 4, 2015

Member

path >= 0 can never be false here.

This comment has been minimized.

@jwueller

jwueller Oct 4, 2015

Contributor

You seem to be correct. This is probably residue from this discussion.

This comment has been minimized.

@trevnorris

trevnorris Oct 6, 2015

Contributor

To clarify, if the user passes readFile('0xff'), would that be interpreted as a file name or file descriptor?

This comment has been minimized.

@jwueller

jwueller Oct 6, 2015

Contributor

This implementation would treat '0xff' as a file name.

This comment has been minimized.

@trevnorris

trevnorris Oct 6, 2015

Contributor

Will all values where typeof === 'number' be treated as a number, all other values will be coerced to a string?

This comment has been minimized.

@jwueller

jwueller Oct 6, 2015

Contributor

The original implementation does not seem to coerce at all. It errors with TypeError: path must be a string instead.

Nevertheless, >>> should always produce a number type, so the strict equality test can only ever succeed for typeof input === 'number', making everything else go down the file name branch, even if that results in another TypeError caused by the path argument not being a string. This behavior remains unchanged.

This comment has been minimized.

@trevnorris

trevnorris Oct 7, 2015

Contributor

I'm pondering how much coercion is allowed. e.g. should we throw on NaN? my instinct is yes. all non uint32 values should throw. Which is exactly what you have now. :)

This comment has been minimized.

@jwueller

jwueller Oct 8, 2015

Contributor

I generally avoid coercion as much as possible. It usually leads to rather unclear behavior. Throwing on NaN sounds like it would be expected. There is no sensible default we can choose in that case.

@ChALkeR

This comment has been minimized.

Member

ChALkeR commented Oct 4, 2015

This is at least semver-minor, but actually looks more like a semver-major to me.
What if someone has done something like

var num = 1;
…
fs.writeFile(num++, …);

Also, the logic is not very clear:

  1. fs.writeFile(1,…) tries to write to file descriptor 1.
  2. fs.writeFile(-1,…) tries to write to file name '-1'.
  3. fs.writeFile(4294967295,…) tries to write to file descriptor 4294967295.
  4. fs.writeFile(4294967296,…) tries to write to file name '4294967296'.

Understandable behavior IMO would be to check if the file name is a string, and if it's not a string nor a valid file descriptor — throw an Error. But that change would be clearly a semver-major.

Not sure what the others think.

Note: I left aside the actual feature introduced by this PR as I have no opinion on that, and covered only the API changes.

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 4, 2015

@ChALkeR First of all, thanks for reviewing this!

fs.writeFile(-1), etc. will actually fail with TypeError: path must be a string, so there does not seem to be a type coercion backwards compatibility problem here. Throwing a dedicated Error in case of neither a string or a plausible file descriptor uint would probably be helpful, though.

@trevnorris actually proposed the uint behavior here, as opposed to going the typeof route. Some additional discussion happened here. Thoughts?

Additionally, maybe @chrisdickinson could shed some light on the originally envisioned behavior as well (original issue link).

@trevnorris

This comment has been minimized.

Contributor

trevnorris commented Oct 7, 2015

What are potential blockers here?

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 8, 2015

Incompatibilities with existing code would definitely be a blocker. Those should not be possible, though. Tests for the original behavior still pass and remain unchanged.

Also, I'll need to do another rebase (and remove the redundant path >= 0 bit).

@ChALkeR

This comment has been minimized.

Member

ChALkeR commented Oct 8, 2015

fs.writeFile(-1), etc. will actually fail with TypeError: path must be a string, so there does not seem to be a type coercion backwards compatibility problem here.

Ah, I overlooked that. So then there should be no backwards-incompatibility here, and this is indeed a semver-minor only?

@trevnorris

This comment has been minimized.

Contributor

trevnorris commented Oct 8, 2015

@ChALkeR This looks like an additive change. All previously accepted inputs are the same, with the addition of supporting uint32's for file descriptors. I'd say this is a semver-minor.

@jwueller jwueller force-pushed the jwueller:fs-optional-file-descriptor-args branch Oct 13, 2015

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 13, 2015

@ChALkeR @trevnorris Rebased and updated!

@trevnorris

View changes

lib/fs.js Outdated
0o666,
req);
if (context.isUserFd) {
req.oncomplete.call(req, null, path);

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

Put this in a nextTick. It's an expected async call, and must always run async.

@trevnorris

View changes

lib/fs.js Outdated
stringToFlags(flag),
0o666,
req);
}

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

return after the if then drop the else.

This comment has been minimized.

@jwueller

jwueller Oct 13, 2015

Contributor

I will adjust this where appropriate.

@trevnorris

View changes

lib/fs.js Outdated
binding.close(this.fd, req);
if (this.isUserFd) {
req.oncomplete.call(req, null);

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

Clarify this with me. If an fd is passed then it isn't automatically closed?

This comment has been minimized.

@jwueller

jwueller Oct 13, 2015

Contributor

Correct. No fd ownership transfer takes place. We did not create the fd, so we should not close it IMHO. Doing so would prevent users from re-using existing file descriptors more than once, pretty much defeating the point of this PR.

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

This needs to be clearly documented. Possibly with big bold text. I can see users thinking they're handing off the fd.

This comment has been minimized.

@jwueller

jwueller Oct 13, 2015

Contributor

Yes, I agree that this is important information. The current patch adds the phrase

Specified file descriptors will not be closed automatically.

to all relevant locations. Do you think the whole thing should be bolded, or just the "not"? I am currently leaning towards emphasizing the whole phrase.

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

It should be in its own paragraph and prefixed with Note:. No need for that to be bold. But having that is common in documentation.

Thanks for working w/ me on this.

@trevnorris

View changes

doc/api/fs.markdown Outdated
@@ -556,7 +564,10 @@ If `options` is a string, then it specifies the encoding. Example:
fs.appendFile('message.txt', 'data to append', 'utf8', callback);
## fs.appendFileSync(filename, data[, options])
Note that any specified file descriptor needs to be opened for appending.
Specified file descriptors will not be closed automatically.

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

Right here. And also in every location where this is true. documentation duplication in all relevant locations is cool.

This comment has been minimized.

@jwueller

jwueller Oct 13, 2015

Contributor

Oops, I missed this comment. Please check my response above. How should this be modified, exactly?

@jwueller jwueller force-pushed the jwueller:fs-optional-file-descriptor-args branch Oct 13, 2015

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 13, 2015

@trevnorris Updated again with the discussed changes.

_Note: Specified file descriptors will not be closed automatically._
## fs.appendFileSync(file, data[, options])

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

I see that you have the note in fs.writeFileSync, but not here in fs.appendFileSync. Is it necessary here?

This comment has been minimized.

@jwueller

jwueller Oct 13, 2015

Contributor

I am not sure what you are asking, exactly. The note is present in all asynchronous versions, while being omitted in the synchronous ones, since the latter segments only refer to the asynchronous documentation anyway.

This comment has been minimized.

@trevnorris

trevnorris Oct 14, 2015

Contributor

Whoop. Sorry. Got lost in the diff. Can see that now.

@trevnorris

View changes

lib/fs.js Outdated
process.nextTick(function() {
req.oncomplete.call(req, null, path);
});

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

can remove this extra line.

@trevnorris

View changes

lib/fs.js Outdated
process.nextTick(function() {
req.oncomplete.call(req, null);
});

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

ditto.

@@ -528,13 +530,21 @@ If `options` is a string, then it specifies the encoding. Example:
fs.writeFile('message.txt', 'Hello Node.js', 'utf8', callback);
## fs.writeFileSync(filename, data[, options])
Any specified file descriptor has to support writing.

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

Mind adding that data written to fd will be appended?

Guess we don't expose an lseek() in fs so users couldn't reposition where data is written. Hm. Future feature.

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

nm. i see what's happening.

This comment has been minimized.

@jwueller

jwueller Oct 13, 2015

Contributor

Whether data will be appended depends on the flags that the fd was created with. The a flags will obviously append, but the w flags will create/truncate instead.

This comment has been minimized.

@trevnorris

trevnorris Oct 13, 2015

Contributor

Yup. I crossed the following code from fs.append:

  if (isFd(path))
    options.flag = 'a';

Sorry

@trevnorris

This comment has been minimized.

Contributor

trevnorris commented Oct 13, 2015

Almost there!

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 13, 2015

After some further digging, I noticed that we have – in fact – several different approaches to dealing with file descriptor arguments available right now:

Method fd Detection fd Ownership Transfer
fs.truncate() typeof path === 'number' none
this PR (path >>> 0) === path none
fs.createReadStream()
fs.createWriteStream()
supplied through options.fd, no type check via options.autoClose (enabled by default)

This makes the PR in it's current form differ from existing functionality. It seems to me we should discuss which of these approaches is the right way to go here.

The latter one does not seem to have existed at the time of writing the original PR (and I did not want to make things more complicated than necessary at the time), but is definitely the most flexible option now that it exists "in the wild".

The behavior of fs.truncate() does not seem desirable. It is behaving strangely, as it automatically delegates to fs.ftruncate(), while other functions with direct fs.f*() counterparts do not. If this is legacy behavior, it likely could be officially deprecated to make the API more uniform. This should probably be the subject of a separate Issue/PR, though. Introducing commit is 168a555, for the record.

@trevnorris

This comment has been minimized.

Contributor

trevnorris commented Oct 13, 2015

I believe how the functionality works in this PR is most appropriate of the differences. So I'd say we proceed with this then work on fixing the other implementations where necessary.

@jwueller jwueller force-pushed the jwueller:fs-optional-file-descriptor-args branch Oct 13, 2015

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 13, 2015

That seems reasonable. Updated again.

@trevnorris

This comment has been minimized.

Contributor

trevnorris commented Oct 14, 2015

Looks great. Running CI one last time for sanity then will land this thing: https://ci.nodejs.org/job/node-test-pull-request/508/

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 14, 2015

Thank you very much for reviewing everything!

@thefourtheye

View changes

lib/fs.js Outdated
var req = new FSReqWrap();
req.context = context;
req.oncomplete = readFileAfterOpen;
if (context.isUserFd) {
process.nextTick(function() {
req.oncomplete.call(req, null, path);

This comment has been minimized.

@thefourtheye

thefourtheye Oct 15, 2015

Contributor

Why not req.oncomplete(null, path)?

This comment has been minimized.

@jwueller

jwueller Oct 15, 2015

Contributor

It would not behave correctly. This call is supposed to emulate the behavior of binding.open(). Omitting the context would lead to incompatibilities with following code (ex: readFileAfterOpen(), where the context is extracted from this).

This comment has been minimized.

@trevnorris

trevnorris Oct 15, 2015

Contributor

the default context is the object to the left of the . so I think @thefourtheye is right in this case.

This comment has been minimized.

@jwueller

jwueller Oct 15, 2015

Contributor

Of course he is. I actually tripped myself there. Sorry! I'll clean that up immediately.

@jwueller jwueller force-pushed the jwueller:fs-optional-file-descriptor-args branch 2 times, most recently to f8ff0a6 Oct 15, 2015

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 15, 2015

@trevnorris One more fix. Thanks @thefourtheye for reviewing!

fs: Add file descriptor support to *File() funcs
These changes affect the following functions and their synchronous
counterparts:

 * fs.readFile()
 * fs.writeFile()
 * fs.appendFile()

If the first parameter is a uint32, it is treated as a file descriptor.
In all other cases, the original implementation is used to ensure
backwards compatibility. File descriptor ownership is never taken from
the user.

The documentation was adjusted to reflect these API changes. A note was
added to make the user aware of file descriptor ownership and the
conditions under which a file descriptor can be used by each of these
functions.

Tests were extended to test for file descriptor parameters under the
conditions noted in the relevant documentation.
@trevnorris

This comment has been minimized.

Contributor

trevnorris commented Oct 15, 2015

Final CI for sanity: https://ci.nodejs.org/job/node-test-pull-request/518/

If CI is good let's land this thing! LGTM

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 16, 2015

@trevnorris Something seems to have failed, but it is not obvious to me what is happening, exactly. Can you help me out?

@trevnorris

This comment has been minimized.

Contributor

trevnorris commented Oct 16, 2015

@jwueller None of the failing tests are related to your PR. Everything seems fine.

trevnorris added a commit that referenced this pull request Oct 16, 2015

fs: add file descriptor support to *File() funcs
These changes affect the following functions and their synchronous
counterparts:

 * fs.readFile()
 * fs.writeFile()
 * fs.appendFile()

If the first parameter is a uint32, it is treated as a file descriptor.
In all other cases, the original implementation is used to ensure
backwards compatibility. File descriptor ownership is never taken from
the user.

The documentation was adjusted to reflect these API changes. A note was
added to make the user aware of file descriptor ownership and the
conditions under which a file descriptor can be used by each of these
functions.

Tests were extended to test for file descriptor parameters under the
conditions noted in the relevant documentation.

PR-URL: #3163
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
@trevnorris

This comment has been minimized.

Contributor

trevnorris commented Oct 16, 2015

Landed on 0803962. Thanks!

Note: This is labelled as semver-minor but it should not land on LTS.

@trevnorris trevnorris closed this Oct 16, 2015

@jwueller

This comment has been minimized.

Contributor

jwueller commented Oct 16, 2015

@trevnorris Great! Thanks again!

@jwueller jwueller deleted the jwueller:fs-optional-file-descriptor-args branch Oct 17, 2015

rvagg added a commit that referenced this pull request Oct 19, 2015

fs: add file descriptor support to *File() funcs
These changes affect the following functions and their synchronous
counterparts:

 * fs.readFile()
 * fs.writeFile()
 * fs.appendFile()

If the first parameter is a uint32, it is treated as a file descriptor.
In all other cases, the original implementation is used to ensure
backwards compatibility. File descriptor ownership is never taken from
the user.

The documentation was adjusted to reflect these API changes. A note was
added to make the user aware of file descriptor ownership and the
conditions under which a file descriptor can be used by each of these
functions.

Tests were extended to test for file descriptor parameters under the
conditions noted in the relevant documentation.

PR-URL: #3163
Reviewed-By: Trevor Norris <trev.norris@gmail.com>

@rvagg rvagg referenced this pull request Oct 21, 2015

Merged

Release proposal: v5.0.0 #3466

rvagg added a commit to rvagg/io.js that referenced this pull request Oct 29, 2015

2015-10-29, Version 5.0.0 (Stable)
Notable changes:

* buffer: (Breaking) Removed both 'raw' and 'raws' encoding types from Buffer,
  these have been deprecated for a long time (Sakthipriyan Vairamani) nodejs#2859.
* console: (Breaking) Values reported by console.time() now have 3 decimals of
  accuracy added (Michaël Zasso) nodejs#3166.
* fs:
  - fs.readFile*(), fs.writeFile*(), and fs.appendFile*() now also accept a file
    descriptor as their first argument (Johannes Wüller) nodejs#3163.
  - (Breaking) In fs.readFile(), if an encoding is specified and the internal
    toString() fails the error is no longer thrown but is passed to the callback
    (Evan Lucas) nodejs#3485.
  - (Breaking) In fs.read() (using the fs.read(fd, length, position, encoding,
    callback) form), if the internal toString() fails the error is no longer
    thrown but is passed to the callback (Evan Lucas) nodejs#3503.
* http:
  - Fixed a bug where pipelined http requests would stall (Fedor Indutny) nodejs#3342.
  - (Breaking) When parsing HTTP, don't add duplicates of the following headers:
    Retry-After, ETag, Last-Modified, Server, Age, Expires. This is in addition
    to the following headers which already block duplicates: Content-Type,
    Content-Length, User-Agent, Referer, Host, Authorization,
    Proxy-Authorization, If-Modified-Since, If-Unmodified-Since, From, Location,
    Max-Forwards (James M Snell) nodejs#3090.
  - (Breaking) The callback argument to OutgoingMessage#setTimeout() must be a
    function or a TypeError is thrown (James M Snell) nodejs#3090.
  - (Breaking) HTTP methods and header names must now conform to the RFC 2616
    "token" rule, a list of allowed characters that excludes control characters
    and a number of separator characters. Specifically, methods and header names
    must now match /^[a-zA-Z0-9_!#$%&'*+.^`|~-]+$/ or a TypeError will be thrown
    (James M Snell) nodejs#2526.
* node:
  - (Breaking) Deprecated the _linklist module (Rich Trott) nodejs#3078.
  - (Breaking) Removed require.paths and require.registerExtension(), both had
    been previously set to throw Error when accessed
    (Sakthipriyan Vairamani) nodejs#2922.
* npm: Upgraded to version 3.3.6 from 2.14.7, see
  https://github.com/npm/npm/releases/tag/v3.3.6 for more details. This is a
  major version bump for npm and it has seen a significant amount of change.
  Please see the original npm v3.0.0 release notes for a list of major changes
  (Rebecca Turner) nodejs#3310.
* src: (Breaking) Bumped NODE_MODULE_VERSION to 47 from 46, this is necessary
  due to the V8 upgrade. Native add-ons will need to be recompiled
  (Rod Vagg) nodejs#3400.
* timers: Attempt to reuse the timer handle for setTimeout().unref(). This fixes
  a long-standing known issue where unrefed timers would perviously hold
  beforeExit open (Fedor Indutny) nodejs#3407.
* tls:
  - Added ALPN Support (Shigeki Ohtsu) nodejs#2564.
  - TLS options can now be passed in an object to createSecurePair()
    (Коренберг Марк) nodejs#2441.
  - (Breaking) The default minimum DH key size for tls.connect() is now 1024
    bits and a warning is shown when DH key size is less than 2048 bits. This a security consideration to prevent "logjam" attacks. A new minDHSize TLS
    option can be used to override the default. (Shigeki Ohtsu) nodejs#1831.
* util:
  - (Breaking) util.p() was deprecated for years, and has now been removed
    (Wyatt Preul) nodejs#3432.
  - (Breaking) util.inherits() can now work with ES6 classes. This is considered
    a breaking change because of potential subtle side-effects caused by a
    change from directly reassigning the prototype of the constructor using
    `ctor.prototype = Object.create(superCtor.prototype, { constructor: { ... } })`
    to using `Object.setPrototypeOf(ctor.prototype, superCtor.prototype)`
    (Michaël Zasso) nodejs#3455.
* v8: (Breaking) Upgraded to 4.6.85.25 from 4.5.103.35 (Ali Ijaz Sheikh) nodejs#3351.
  - Implements the spread operator, see
    https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator
    for further information.
  - Implements new.target, see
    https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new.target
    for further information.
* zlib: Decompression now throws on truncated input (e.g. unexpected end of
  file) (Yuval Brik) nodejs#2595.

PR-URL: nodejs#3466

rvagg added a commit that referenced this pull request Oct 29, 2015

2015-10-29, Version 5.0.0 (Stable)
Notable changes:

* buffer: (Breaking) Removed both 'raw' and 'raws' encoding types from Buffer,
  these have been deprecated for a long time (Sakthipriyan Vairamani) #2859.
* console: (Breaking) Values reported by console.time() now have 3 decimals of
  accuracy added (Michaël Zasso) #3166.
* fs:
  - fs.readFile*(), fs.writeFile*(), and fs.appendFile*() now also accept a file
    descriptor as their first argument (Johannes Wüller) #3163.
  - (Breaking) In fs.readFile(), if an encoding is specified and the internal
    toString() fails the error is no longer thrown but is passed to the callback
    (Evan Lucas) #3485.
  - (Breaking) In fs.read() (using the fs.read(fd, length, position, encoding,
    callback) form), if the internal toString() fails the error is no longer
    thrown but is passed to the callback (Evan Lucas) #3503.
* http:
  - Fixed a bug where pipelined http requests would stall (Fedor Indutny) #3342.
  - (Breaking) When parsing HTTP, don't add duplicates of the following headers:
    Retry-After, ETag, Last-Modified, Server, Age, Expires. This is in addition
    to the following headers which already block duplicates: Content-Type,
    Content-Length, User-Agent, Referer, Host, Authorization,
    Proxy-Authorization, If-Modified-Since, If-Unmodified-Since, From, Location,
    Max-Forwards (James M Snell) #3090.
  - (Breaking) The callback argument to OutgoingMessage#setTimeout() must be a
    function or a TypeError is thrown (James M Snell) #3090.
  - (Breaking) HTTP methods and header names must now conform to the RFC 2616
    "token" rule, a list of allowed characters that excludes control characters
    and a number of separator characters. Specifically, methods and header names
    must now match /^[a-zA-Z0-9_!#$%&'*+.^`|~-]+$/ or a TypeError will be thrown
    (James M Snell) #2526.
* node:
  - (Breaking) Deprecated the _linklist module (Rich Trott) #3078.
  - (Breaking) Removed require.paths and require.registerExtension(), both had
    been previously set to throw Error when accessed
    (Sakthipriyan Vairamani) #2922.
* npm: Upgraded to version 3.3.6 from 2.14.7, see
  https://github.com/npm/npm/releases/tag/v3.3.6 for more details. This is a
  major version bump for npm and it has seen a significant amount of change.
  Please see the original npm v3.0.0 release notes for a list of major changes
  (Rebecca Turner) #3310.
* src: (Breaking) Bumped NODE_MODULE_VERSION to 47 from 46, this is necessary
  due to the V8 upgrade. Native add-ons will need to be recompiled
  (Rod Vagg) #3400.
* timers: Attempt to reuse the timer handle for setTimeout().unref(). This fixes
  a long-standing known issue where unrefed timers would perviously hold
  beforeExit open (Fedor Indutny) #3407.
* tls:
  - Added ALPN Support (Shigeki Ohtsu) #2564.
  - TLS options can now be passed in an object to createSecurePair()
    (Коренберг Марк) #2441.
  - (Breaking) The default minimum DH key size for tls.connect() is now 1024
    bits and a warning is shown when DH key size is less than 2048 bits. This a security consideration to prevent "logjam" attacks. A new minDHSize TLS
    option can be used to override the default. (Shigeki Ohtsu) #1831.
* util:
  - (Breaking) util.p() was deprecated for years, and has now been removed
    (Wyatt Preul) #3432.
  - (Breaking) util.inherits() can now work with ES6 classes. This is considered
    a breaking change because of potential subtle side-effects caused by a
    change from directly reassigning the prototype of the constructor using
    `ctor.prototype = Object.create(superCtor.prototype, { constructor: { ... } })`
    to using `Object.setPrototypeOf(ctor.prototype, superCtor.prototype)`
    (Michaël Zasso) #3455.
* v8: (Breaking) Upgraded to 4.6.85.25 from 4.5.103.35 (Ali Ijaz Sheikh) #3351.
  - Implements the spread operator, see
    https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator
    for further information.
  - Implements new.target, see
    https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new.target
    for further information.
* zlib: Decompression now throws on truncated input (e.g. unexpected end of
  file) (Yuval Brik) #2595.

PR-URL: #3466

@sam-github sam-github referenced this pull request Jan 17, 2017

Closed

doc: clarify the behavior of readFile with fd #10853

2 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment