There was no need to share state between C++ and JS for these two
values. So they have been moved to their respective locations. This will
help performance only a tiny bit, but it does help code complexity much
more.
We need to keep ObjectWrap around for module authors (we think), but
v8 3.21 broke node_object_wrap.h with respect to MSVC. Coincidentally,
we no longer use ObjectWrap at all in core, and native modules might
as well use their own entirely internal implementation if they need it.
Turns out that we don't use node_object_wrap.h any more in core,
and, with v8 3.21, it's breaking our Windows build. Removing refs
to it everywhere (and adding node.h in one case where it was the
only way node.h was being included), we have restored the Windows
build.
Previous behaviour was to drop to an openssl prompt
("Enter PEM pass phrase:") when supplying a private key with a
passphrase. This change adds a fourth, optional, paramter that
will be used as the passphrase.
To include this parameter in a backwards compatible way it was
necessary to expose the previously undocumented (and unexposed)
feature of being able to explitly setting the output encoding.
This addresses a current shortcoming of the V8 SetNamedPropertyHandler
function.
It does not provide a way to intercept Object.defineProperty(..) calls.
As a result, these properties are not copied onto the contextified
sandbox when a new global property is added via either a function
declaration or a Object.defineProperty(global, ...) call.
Note that any function declarations or Object.defineProperty() globals
that are created asynchronously (in a setTimeout, callback, etc.) will
happen AFTER the call to copy properties, and thus not be caught.
The way to properly fix this is to add some sort of a
Object::SetNamedDefinePropertyHandler() function that takes a callback,
which receives the property name and property descriptor as arguments.
Luckily, such situations are rare, and asynchronously-added globals
weren't supported by Node's VM module until 0.12 anyway. But, this
should be fixed properly in V8, and this copy function should be removed
once there is a better way.
Fix#6416
The list of supported HTTP methods is available in JS land now so there
is no longer any need to pass a stringified version of the method to the
parser callback, it can look up the method name for itself.
Saves a call to v8::Eternal::Get() in the common case and a costly
v8::String::NewFromOneByte() in the uncommon case.
Make the build rule depend on the build artifact (weakref.node) itself
rather than the directory it's built in. Depending on the directory
means that a build failure won't trigger a rebuild on the next
invocation because the directory's timestamp has been updated.
This is a back-port of commit 1189571 from the master branch that
hopefully fixes the following CI error:
executing: make test/gc/node_modules/weak/build/
make: *** No rule to make target `test/gc/node_modules/weak/build/'.
Command exited with non-zero: make test/gc/node_modules/weak/build/
Build step 'Execute NodeJS script' marked build as failure
When the socket closes, the client's http incoming message object was
emitting an 'aborted' event if it had not yet been ended.
However, it's possible, when a response is being repeatedly paused and
resumed (eg, if piped to a slow FS write stream), that there will be a
final chunk remaining in the js-land buffer when the socket is torn
down.
When that happens, the socketCloseListener function detects that we have
not yet reached the end of the response message data, and treats this as
an abrupt abort, immediately (and forcibly) ending the incoming message
data stream, and discarding that final chunk of data.
The result is that, for example, npm will have problems because tarballs
are missing a few bytes off the end, every time.
Closes GH-6402
Make the build rule depend on the build artifact (weakref.node) itself
rather than the directory it's built in. Depending on the directory
means that a build failure won't trigger a rebuild on the next
invocation because the directory's timestamp has been updated.
If a client sends a lot more pipelined requests than we can handle, then
we need to provide backpressure so that the client knows to back off.
Do this by pausing both the stream and the parser itself when the
responses are not being read by the downstream client.
Backport of 085dd30
- fixed some incomprehensible wording ("event assigned to..."?)
- removed undocumented and unnecessary process properties from example
- corrected the docs on the default for the exec setting
- described when workers are removed from cluster.workers
- described addressType, which was documented as existing, but not what
values it might have
- spell out more clearly the limitations of setupMaster
- describe disconnect in sufficient detail that why a child does or does
not exit can be understood
- clarify which cluster functions and events are available on process or
just on the worker, as well as which are not available in children,
- don't describe events as the same, when they have receive different
arguments
- fix misleading disconnect example: since disconnect already calls
close on all servers, doing it again in the example is a no-op, not
the "force close" it was claimed to be
- document the error event, not catching it will kill your node
- describe suicide better, it is important, and a bit unintuitive
(process.exit() is not suicide?)
- use worker consistently throughout, instead of child.
- Make explicit that .disconnected is set before the disconnect event,
and it is not allowed to send messages after calling .disconnect(),
even while waiting for a delayed disconect event.
- Remove obsolete claim that explicit exit is required
- Describe silent: in the options for fork()
- Describe .connected as the property it is, not just as an aside in
the disconnect() method
A follow-up commit will save the domain name on the request object but
we can't call that property 'domain' because that gets intercepted by
src/node.cc and lib/domain.js to implement the node.js feature of the
same name.
To avoid confusion, rename all variables called 'domain' to 'hostname'.
Before this commit, the SIGUSR1 signal handler wasn't installed until
late in the bootstrapping process and we were prone to miss signals
sent by other processes.
This commit installs an early-boot signal handler that merely records
the fact that we received a signal. Once the debugger infrastructure
is in place, the signal is re-raised, kickstarting the debugger.
Among other things, this means that simple/test-debugger-client is
now _much_ less likely to fail.
Commit 30e5366b ("core: Use a uv_signal for debug listener") changed
SIGUSR1 handling from a signal handler to libuv's uv_signal_*()
functionality to fix a race condition (and possible hang) in the
signal handler.
While a good change in itself, it made it impossible to interrupt
long running scripts. When a script is stuck in a busy loop, control
never returns to the event loop, which in turn means the signal
callback - and therefore the debugger - is never invoked.
This commit changes SIGUSR1 handling back to a normal signal handler
but one that treads _very_ carefully.
If a client sends a lot more pipelined requests than we can handle, then
we need to provide backpressure so that the client knows to back off.
Do this by pausing both the stream and the parser itself when the
responses are not being read by the downstream client.
Fix GH-6214
Add a short explanation of what the load average is and why it's
unavailable on Windows.
Also sneak in a fix for a typo that I introduced in commit 56c5806.
Don't emit the 'disconnect' event until all workers have gone away.
Before this commit, the event was emitted when all open handles were
closed, which usually - but not always - amounts to the same thing.
Fixes#6346.
Because it's possible for the data within a Buffer instance to be
altered after instantiation, or in case a user attempts to do something
like the following:
Buffer.prototype.fill.call({}, 10, 0, 10);
It doesn't result in a segfault.
* Extend examples to show how to handle non-constructor invocation in
constructor callback functions.
* Fix up examples to initialize member variables at object construction.
* Fix up a few naming inconsistencies.
Fixes#5701.
Destroying the TLS session implies destroying the underlying socket but
before this commit, that was done with net.Socket#destroy() rather than
net.Socket#destroySoon(). The former closes the connection right away,
even when there is still data to write. In other words, sometimes the
final TLS record got truncated.
Fixes#6107.
This change makes several improvements to the ustack helper and MDB
support:
- ustack helper and MDB: add support for two-byte strings
(necessary to print many filenames in stacktraces in 0.10 and later).
- ustack helper: fix position numbers, which were off by a factor of two
- ustack helper: fix frames with undefined Scripts (e.g., "RegExp")
- ustack helper: add stub frames
- MDB: add support for sliced strings
- MDB: sync up with changes from the illumos version of the module
Fixes#6309Closes#6318
fs.truncate() and its synchronous sibling are implemented in terms of
open() + ftruncate(). Unfortunately, it opened the target file with
mode 'w' a.k.a. 'write-only and create or truncate at open'.
The subsequent call to ftruncate() then moved the end-of-file pointer
from zero to the requested offset with the net result of a file that's
neatly truncated at the right offset and filled with zero bytes only.
This bug was introduced in commit 168a5557 but in fairness, before that
commit fs.truncate() worked like fs.ftruncate() so it seems we've never
had a working fs.truncate() until now.
Fixes#6233.
Mea culpa, I didn't properly resolve a merge conflict in the last two
commits. The resulting segmentation fault only happened on Linux and
only sometimes.
Fixes#6306.
The previous commit changes the profiler idle notifier so that it only
gets started when a --prof or --prof_lazy argument is specified on the
command line.
This commit adds two internal methods to the process object that allows
one to start and stop the idle notifier programmatically.
The previous commit adds a notifier that tells the V8 profiler when
node.js is idle, i.e. when it's about to start sleeping in the
platform's equivalent of epoll_wait().
This commit adds a heuristic that only starts the notifier when the
V8 profiler is started from the command line.
Inform V8's CPU profiler when we're idle. The profiler is
sampling-based but not all samples are created equal; mark the wall
clock time spent in epoll_wait() and friends so profiling tools can
filter it out. The samples still end up in v8.log but with state=IDLE
rather than state=EXTERNAL.
I haven't actually tested this code, but was reading it due to a
post that linked to the code here:
http://dailyjs.com/2013/09/26/libuv/
As I was reading through the code, I noticed a path that can't
be reached.
I didn't strictly follow the contributing guide:
https://github.com/joyent/node/wiki/Contributing
but the change seems safe.
Feel free to close this out. I'm not sure if it was just an oversight
or what.
Drop the ObjectWrap dependency in favor of an internal WeakObject class.
Let's us stop worrying about API and ABI compatibility when making
changes to the way node.js deals with weakly persistent handles
internally.
After the upgrade from 3.20.17.7 to 3.20.17.11, we've begun hitting
random assertions in V8 in memory-constrained / GC-heavy situations.
The assertions all seem to be related to heap allocations and garbage
collection but apart from that, they're all over the place.
This reverts commit 970bdccc38.
The default entropy source is /dev/urandom on UNIX platforms, which is
okay but we can do better by seeding it from OpenSSL's entropy pool.
On Windows we can certainly do better; on that platform, V8 seeds the
random number generator using only the current system time.
Fixes#6250.
The test case from the previous commit exposed a regression in the way
that c-ares errors are reported to JS land. Said regression was
introduced in commit 756b622 ("src: add multi-context support").
Fixes the following test failure:
$ out/Release/node test/simple/test-dns-regress-6244
util.js:675
var errname = uv.errname(err);
^
Error: err >= 0
at Object.exports._errnoException (util.js:675:20)
at errnoException (dns.js:43:15)
at Object.onresolve [as oncomplete] (dns.js:145:19)
lib/dns.js erroneously assumed that the error code was a libuv error
code when it's really a c-ares status code. Libuv handles getaddrinfo()
style lookups (which is by far the most common type of lookup), that's
why this bug wasn't discovered earlier.
Don't forget to initialize the c-ares task tree head when creating a
new Environment. Oversight from the multi-context work that landed
in commit 756b622.
Fixes#6244.
Fix "Assertion failed" when trying to connect to non-int ports:
Assertion failed: (args[2]->Uint32Value()), function Connect,
file ../src/tcp_wrap.cc, line 379.
Abort trap: 6
Apparently, context->Global() won't be destroyed if the context itself
isn't marked as weak and independent.
Also, the weakness flag should be cleared once the weak callback is
executed, otherwise we'll get crashes in Debug builds.
fix#6115 and #6201
The `options` that were being passed in before here are specific to a
single request, which kinda defeats the purpose of using an Agent in the
first place.
On a worse note, these `options` have not yet been "processed" by the
`http.ClientRequest` class, so if `port: null` is set (like it is as the
result of a `url.parse()` call), then they take preference over the
processed values since the agent's "options" get mixed in last in the
`createSocket()` function.
Fixes#6197.
Fixes#6199.
Closes#6231.
Otherwise the data ends up "on the wire" twice, and
switching between consuming the stream using `ondata`
vs. `read()` would yield duplicate data, which was bad.
Apparently Joyent decommissioned joyeur.com but at least they saved the
contents of the blog. Update the links in the README and the nodejs.org
blog posts.
Hat tip to Eugen Pirogoff (@eugenpirogoff) for pointing it out.
Fixes#6224.
Functions created using: `vm.runInNewContext('(function() { })')` will
reference only `proxy_global_` object and not `sandbox_`. Thus in case,
where there're no references to sandbox (such as in example above),
`ContextifyContext` will be destroyed and use-after-free might happen.
String#toLowerCase() is incredibly slow and was costing a 15-30%
performance hit for Buffers less than 1KB. Now instead it'll attempt to
find the correct encoding directly from the passed encoding, only then
afterwards it'll lowercase.
The optimization for not passing any encoding at all is still at the top
of the method.
At most this may add 10% performance hit for passing a mixed case
encoding.
The NPN protocols was set on `require('tls')` or `global` object instead
of being a local property. This fact lead to strange persistence of NPN
protocols, and sometimes incorrect protocol selection (when no NPN
protocols were passed in client options).
fix#6168
Slowness being somewhat subjective but determined by running the
test suite a few times and picking off everything that consistently
clocks in at 2 seconds or more.
Honorable mention for simple/test-tls-server-large-request, it often
runs for 10 (!) seconds or more.
Since it is Unix tradition to use exit code 1 for general-purpose script
bail-out, and the way of doing that in Node is to throw an exception and
not catch it, it makes the most sense to exit with 1 when an exception
goes uncaught.
Move the `Invalid Argument` exit to 9, so that it's something specific,
and clear that it's a node internal error.
Also, document the exit codes that we use.
Fix pointer unwrapping when T is a class with more than one base class.
Before this commit, the wrapped void* pointer was cast directly to T*
without going through ObjectWrap* first, possibly leading to a class
instance pointer that points to the wrong vtable.
This change required some cleanup in various files; some classes
used private rather than public inheritance, others didn't derive
from ObjectWrap at all...
Fixes#6188.
This commit makes it possible to use multiple V8 execution contexts
within a single event loop. Put another way, handle and request wrap
objects now "remember" the context they belong to and switch back to
that context when the time comes to call into JS land.
This could have been done in a quick and hacky way by calling
v8::Object::GetCreationContext() on the wrap object right before
making a callback but that leaves a fairly wide margin for bugs.
Instead, we make the context explicit through a new Environment class
that encapsulates everything (or almost everything) that belongs to
the context. Variables that used to be a static or a global are now
members of the aforementioned class. An additional benefit is that
this approach should make it relatively straightforward to add full
isolate support in due course.
There is no JavaScript API yet but that will be added in the near
future.
This work was graciously sponsored by GitHub, Inc.
From commit 756ae2c all the WRAP/UNWRAP were moved to a single location
for ease of use. In a single location NO_ABORT should have been used but
wasn't. This caused HandleWrap::Close to abort. Below is the applicable
code change as demonstration there was no abort specified when
unwrapping the object.
void HandleWrap::Close(const FunctionCallbackInfo<Value>& args) {
HandleScope scope(node_isolate);
- HandleWrap *wrap = static_cast<HandleWrap*>(
- args.This()->GetAlignedPointerFromInternalField(0));
+ HandleWrap* wrap;
+ UNWRAP(args.This(), HandleWrap, wrap);
Also included a test that will reproduce the abort.
Stop gcc from getting confused, explicitly cast the return value from
getuid() and getgid() to uint32_t. Fixes the following build error:
../src/node.cc: In function 'void node::GetUid(const
v8::FunctionCallbackInfo<v8::Value>&)':
../src/node.cc:1552:37: error: call of overloaded 'Set(uid_t)' is
ambiguous
../src/node.cc:1552:37: note: candidates are:
../deps/v8/include/v8.h:5939:6: note: void
v8::ReturnValue<T>::Set(bool) [with T = v8::Value]
../deps/v8/include/v8.h:5909:6: note: void
v8::ReturnValue<T>::Set(double) [with T = v8::Value]
../deps/v8/include/v8.h:5915:6: note: void
v8::ReturnValue<T>::Set(int32_t) [with T = v8::Value, int32_t = int]
../deps/v8/include/v8.h:5926:6: note: void
v8::ReturnValue<T>::Set(uint32_t) [with T = v8::Value, uint32_t =
unsigned int]
Fixes#6182.
In cases where the Agent has maxSockets=Infinity, and
keepAlive=false, there's no case where we won't immediately close the
connection after the response is completed.
Since we're going to close it anyway, send a `connection:close` header
rather than a `connection:keep-alive` header. Still send the
`connection:keep-alive` if the agent will actually reuse the socket,
however.
Closes#5838
This simplifies the logic that was in isSyntaxError, as well as the
choice to wrap command input in parens to coerce to an expression
statement.
1. Rather than a growing blacklist of allowed-to-throw syntax errors,
just sniff for the one we really care about ("Unexpected end of input")
and let all the others pass through.
2. Wrapping {a:1} in parens makes sense, because blocks and line labels
are silly and confusing and should not be in JavaScript at all.
However, wrapping functions and other types of programs in parens is
weird and required yet *more* hacking to work around. By only wrapping
statements that start with { and end with }, we can handle the confusing
use-case, without having to then do extra work for functions and other
cases.
This also fixes the repl wart where `console.log)(` works in the repl,
but only by virtue of the fact that it's wrapped in parens first, as
well as potential side effects of double-running the commands, such as:
> x = 1
1
> eval('x++; throw new SyntaxError("e")')
... ^C
> x
3
Adding a new `repl-harmony` test file here because adding the
`--use_strict --harmony` flags on the main repl test file was causing
lots of unrelated failures, due to global variable assignments and
things like that. This new test file is based off of the original
repl.js test file, but has a lot of the tests stripped out. A test case
for this commit is included though.
Fixes#6132.
Replace the growing list of 'isSyntaxError' whackamole conditions with a
smarter approach. This creates a vm Script object *first*, which will
parse the code and raise a SyntaxError right away.
We still do need the test function, but only because strict mode syntax
errors are not recoverable, and should be raised right away. Really, we
should probably *only* continue on "unexpected end of input" SyntaxErrors.
Also fixes a very difficult-to-test nit where the '...' indentation is
not properly cleared when you ^C out of a syntax error.
Closes#6093
This commit changes src/tcp_wrap.cc and src/udp_wrap.cc just enough to
get by (i.e. to compile and function correctly.)
The new libuv API allows for more cleanup and deduplication but I'm
saving that for another day.
If the string is external then the length can be quickly retrieved. This
is especially faster for large strings that are being treated as UTF8.
Also, if the string is external then there's no need for a full
String::WriteUtf8 operation. A simple memcpy will do.
This is useful when we need to push some debugging messages out to
stderr, without going through the Writable class, or triggering any kind
of nextTick or callback behavior.
* Exit with an error message when the option is not a node or V8 option.
* Remove the option_end_index global. Needs to happen anyway for
the multi-context work, might as well land it in master now.
* Add a smidgen of const-correctness.
* Pay off a few years of accrued technical debt.
Don't wait a full second before starting the watcher, 10 ms ought to be
more than enough time. Reduces running time from 1250 ms to 250 ms on
my system.
Don't call uv_loop_delete() until we've figured out a way to gracefully
close open handles. See also commit 4915884 and its subsequent revert
in commit 980cbd5.
This reverts commit 556b890ad9.
This change is not entirely ready for prime time: it's making ~50 tests
fail on Windows, mostly due to timeouts. It's up for debate who is
at fault here: node.js or libuv.
It does however expose a libuv bug on OS X, where the event loop
sometimes gets stuck in uv__io_poll() when there is a single
UV_SHUTDOWN request left in the queue. Needs further investigation.
This reverts commit 4915884da6.
Commit 556b890 added a call to uv_loop_delete() with the intent of
catching handle lifecycle bugs. It worked because it exposed one:
process.on('exit', function() {
console.log('bye'); // Asserts.
});
When run, it asserts with the following message:
Assertion failed: (!uv__has_active_reqs(loop)), function
uv__loop_delete, file ../deps/uv/src/unix/loop.c, line 150.
That's because libuv as of joyent/libuv@3f2d4d5 checks that there are
no in-flight requests when the event loop is destroyed. In the test
case above, the write request for the string hasn't completed yet by
the time node.js exits: the string itself has most likely been written
but libuv hasn't had the opportunity to return the write request to
node.js.
That's why this commit adds a cleanup step right before exit where it
explicitly closes all open handles, then waits until the event loop
exits naturally.
Named pipes (UNIX domain sockets) are shut down first in order to flush
pending write requests. Should go some way towards fixing the Windows
issue where output on stdout/stderr sometimes gets truncated.
Fixesjoyent/libuv#911.
Remove NodeBIO::GetMethod() and replace calls to BIO_new() with calls
to the new NodeBIO::New() function.
This commit basically reshuffles some code in order to make it explicit
that the NodeBIO BIO_METHOD is const.
Before this commit it was declared static (in a header file!), meaning
it got duplicated in every file that includes it.
A few duplicated pointers is not the end of the world but it introduces
a lot of potential for confusion because root_cert_store in file A is
not the root_cert_store in file B.
Moral of the story: don't declare static variables in header files.
- The caveats no longer apply.
- Document options arguments, including `displayErrors` and the
different things it means in each place.
- Re-did examples to be more on point, e.g. `runInContext` example
runs multiple scripts in the same context.
- Documented how `vm.createContext`s meaning has substantially changed,
and is now more of a "contextifier" than a "creator."
- Reordered vm functions to be readable in order; the concept of
contextifying needs to come before `runInContext` and
`runInNewContext`.
- Documented new `vm.isContext`.
- Documented the `vm.Script` constructor, instead of `createScript`,
since factory methods are silly and we wanted to document the class's
methods anyway.
- Documented `script.runInContext`.
- Change stability to stable, if I may be so bold.
Passing a filename is still supported in place of certain options
arguments, for backward-compatibility, but timeout and display-errors
are not translated since those were undocumented.
Also managed to eliminate an extra stack trace line by not calling
through the `createScript` export.
Added a few message tests to show how `displayErrors` works.
In `Timer.now` always update the loop time by calling uv_update_time.
Previously we were trying to cache the loop time to prevent extra
syscalls. While a noble goal, it can cause timers to fire early in
certain circumstances. Especially seen in cpu bound work loads or work
loads with synchronous file operations.
Previously, calling `vm.createContext(o)` repeatedly on the same `o`
would cause new C++ `ContextifyContext`s to be created and stored on
`o`, while the previous resident went off into leaked-memory limbo.
Now, repeatedly trying to contextify a sandbox will do nothing after
the first time.
To detect this, an independently-useful `vm.isContext(sandbox)` export
was added.
This was a remnant of the original Contextify code, wherein
ContextifyContext was a user-exposed object. In vm, it is not, so all
of the ObjectWrap and function-template stuff for the ContextifyContext
constructor is now unnecessary.
There's no need to create a new Buffer instance if we're just going to
immediately call toString() at the end anyway. Better to create a
string up front, and setEncoding() on the streams, and do a string
concatenation instead.
Since the encoding is no longer relevant once it is decoded to a Buffer,
it is confusing and incorrect to pass the encoding as 'utf8' or whatever
in those cases.
Closes#6119
Length arguments passed to SlowBuffer were coerced to Int32, not Uint32,
so passing a negative number would throw the following:
node: ../src/smalloc.cc:244: void node::smalloc::Alloc(): Assertion `length <= kMaxLength' failed.
Aborted (core dumped)
That has been fixed by coercing to Uint32 and comparing the value
against kMaxLength.
Due to a lot of the util.is* checks there was much unnecessary overhead
for the most common use case of Buffer. Which is creating a new Buffer
instance for data from incoming I/O. NativeBuffer is a simple way to
bypass all the unneeded checks and simply hand back a Buffer instance
while setting the length.
On windows process exit codes can be greater than INT32_MAX. This used
to be not much of a problem - greater values would just come out
negative. However since ca9eb71 a negative result value indicates that
uv_spawn() has failed, so this is no longer acceptable.
Instead of doing all the domain handling in core, allow the domain to
set an error handler that'll take care of it all. This way the domain
error handling can be abstracted enough for any user to use it.
All the Buffer#{ascii,hex,etc.}Slice() methods are intentionally strict
to alert if a Buffer instance was attempting to be accessed out of
bounds. Buffer#toString() is the more user friendly way of accessing the
data, and will coerce values to their min/max on overflow.
This is an important part of the repl use-case.
TODO: The arg parsing in vm.runIn*Context() is rather wonky.
It would be good to move more of that into the Script class,
and/or an options object.
As documented in #3042 and in [1], the existing vm implementation has
many problems. All of these are solved by @brianmcd's [contextify][2]
package. This commit uses contextify as a conceptual base and its code
core to overhaul the vm module and fix its many edge cases and caveats.
Functionally, this fixes#3042. In particular:
- A context is now indistinguishable from the object it is based on
(the "sandbox"). A context is simply a sandbox that has been marked
by the vm module, via `vm.createContext`, with special internal
information that allows scripts to be run inside of it.
- Consequently, items added to the context from anywhere are
immediately visible to all code that can access that context, both
inside and outside the virtual machine.
This commit also smooths over the API very slightly:
- Parameter defaults are now uniformly triggered via `undefined`, per
ES6 semantics and previous discussion at [3].
- Several undocumented and problematic features have been removed, e.g.
the conflation of `vm.Script` with `vm` itself, and the fact that
`Script` instances also had all static `vm` methods. The API is now
exactly as documented (although arguably the existence of the
`vm.Script` export is not yet documented, just the `Script` class
itself).
In terms of implementation, this replaces node_script.cc with
node_contextify.cc, which is derived originally from [4] (see [5]) but
has since undergone extensive modifications and iterations to expose
the most useful C++ API and use the coding conventions and utilities of
Node core.
The bindings exposed by `process.binding('contextify')`
(node_contextify.cc) replace those formerly exposed by
`process.binding('evals')` (node_script.cc). They are:
- ContextifyScript(code, [filename]), with methods:
- runInThisContext()
- runInContext(sandbox, [timeout])
- makeContext(sandbox)
From this, the vm.js file builds the entire documented vm module API.
node.js and module.js were modified to use this new native binding, or
the vm module itself where possible. This introduces an extra line or
two into the stack traces of module compilation (and thus into most
stack traces), explaining the changed tests.
The tests were also updated slightly, with all vm-related simple tests
consolidated as test/simple/test-vm-* (some of them were formerly
test/simple/test-script-*). At the same time they switched from
`common.debug` to `console.error` and were updated to use
`assert.throws` instead of rolling their own error-testing methods.
New tests were also added, of course, demonstrating the new
capabilities and fixes.
[1]: http://nodejs.org/docs/v0.10.16/api/vm.html#vm_caveats
[2]: https://github.com/brianmcd/contextify
[3]: https://github.com/joyent/node/issues/5323#issuecomment-20250726
[4]: bf123f3ef9/src/contextify.cc
[5]: https://gist.github.com/domenic/6068120
* uv: Upgrade v0.10.14
* http_parser: Do not accept PUN/GEM methods as PUT/GET (Chris Dickinson)
* tls: fix assertion when ssl is destroyed at read (Fedor Indutny)
* stream: Throw on 'error' if listeners removed (isaacs)
* dgram: fix assertion on bad send() arguments (Ben Noordhuis)
* readline: pause stdin before turning off terminal raw mode (Daniel Chatfield)
`maybeInitFinished()` can emit the 'secure' event which
in turn destroys the connection in case of authentication
failure and sets `this.pair.ssl` to `null`.
If such condition appeared after non-empty read - loop will continue
and `clearOut` will be called on `null` object instead of
`crypto::Connection` instance. Resulting in the following assertion:
ERROR: Error: Hostname/IP doesn't match certificate's altnames
Assertion failed: handle->InternalFieldCount() > 0
fix#5756
The C++ API has been changed so the passed length is the byte size of
the data, not the length of the array.
This was done so users need to explicitly define how much memory they
want allocated.
`dns.lookup` defaults to selecting IPv4 record even if IPv6 is available
for the desired zone. Generally, this approach works, but if IPv4
address is unavailable - there'll be no other way to opt-out and connect using
IPv6 address than calling `dns.lookup` and passing it to `.connect()`
directly.
This commit adds `family` option to `net.connect` method to figure out
this issue.
It only fails once in about 1000 times, but that's too many.
It's timing dependent, and the main behavior is covered by the other
assertions in the test anyway.
This change is 100% backwards compatible.
This change will make using `EventEmitter` slightly simpler / nicer and
adheres to the best practice set forth by substack.
```js
var EventEmitter = require("events")
var emitter = new EventEmitter()
```
The only difference is that we now have to set `EventEmitter` as a
property of `EventEmitter` for backwards compatibility like we do with
[`Stream`][1]
We have also set the `usingDomains` property on the `EventEmitter`
constructor itself because that aligns with it's current usage of
`require("events").usingDomains = true`
There are other internals that would benefit from this change as well
like `StringDecoder`
This allows automatically-inserted headers to be removed permanently by
calling OutgoingMessage.removeHeader() on them, as if they were normal
headers.
In this situation:
writable.on('error', handler);
readable.pipe(writable);
writable.removeListener('error', handler);
writable.emit('error', new Error('boom'));
there is actually no error handler, but it doesn't throw, because of the
fix for stream.once('error', handler), in 23d92ec.
Note that simply reverting that change is not valid either, because
otherwise this will emit twice, being handled the first time, and then
throwing the second:
writable.once('error', handler);
readable.pipe(writable);
writable.emit('error', new Error('boom'));
Fix this with a horrible hack to make the stream pipe onerror handler
added before any other userland handlers, so that our handler is not
affected by adding or removing any userland handlers.
Closes#6007.
Commit 03e008d introduced src/tls_wrap.cc and src/tls_wrap.h but
said files copied on the order of 1 kLoC from src/node_crypto.cc
and src/node_crypto.h. This commit undoes some of the duplication.
Fixes#6024.
Add range checks for the offset, length and port arguments to
dgram.Socket#send(). Fixes the following assertion:
node: ../../src/udp_wrap.cc:264: static v8::Handle<v8::Value>
node::UDPWrap::DoSend(const v8::Arguments&, int): Assertion
`offset < Buffer::Length(buffer_obj)' failed.
And:
node: ../../src/udp_wrap.cc:265: static v8::Handle<v8::Value>
node::UDPWrap::DoSend(const v8::Arguments&, int): Assertion
`length <= Buffer::Length(buffer_obj) - offset' failed.
Interestingly enough, a negative port number was accepted until now but
silently ignored. (In other words, it would send the datagram to a
random port.)
This commit exposed a bug in the simple/test-dgram-close test which
has also been fixed.
This is a back-port of commit 41ec6d0 from the master branch.
Fixes#6025.
On windows, libuv will immediately make a `ReadConsole` call (in the
thread pool) when a 'flowing' `uv_tty_t` handle is switched to
line-buffered mode. That causes an immediate issue for some users,
since libuv can't cancel the `ReadConsole` operation on Windows 8 /
Server 2012 and up if the program switches back to raw mode later.
But even if this will be fixed in libuv at some point, it's better to
avoid the overhead of starting work in the thread pool and immediately
cancelling it afther that.
See also f34f1e3, where the same change is made for the opposite
flow, e.g. move `resume()` after `_setRawMode(true)`.
Fixes#5927
This is a backport of dfb0461 (see #5930) to the v0.10 branch.
On windows, libuv will immediately make a `ReadConsole` call (in the
thread pool) when a 'flowing' `uv_tty_t` handle is switched to
line-buffered mode. That causes an immediate issue for some users,
since libuv can't cancel the `ReadConsole` operation on Windows 8 /
Server 2012 and up if the program switches back to raw mode later.
But even if this will be fixed in libuv at some point, it's better to
avoid the overhead of starting work in the thread pool and immediately
cancelling it afther that.
See also f34f1e3, where the same change is made for the opposite
flow, e.g. move `resume()` after `_setRawMode(true)`.
Fixes#5927Closes#5930
RandomBytes() allocated memory with new[] which was then handed off to
Buffer::Use() which eventually releases it again with free().
Mixing the two is technically a violation of the spec and besides, it's
generally frowned upon.
In other Writable streams, the 'finish' event means that all of the data
was written, and flushed to the underlying system.
The 'prefinish' event means that end() was called, and all of the data
was processed, but not necessarily completely flushed.
This change brings the http OutgoingMessage classes more in sync with
the other Writable classes throughout Node.
Unfortunately, this change highlights an issue with http
IncomingMessages, where the _dump() method will not actually pull the
data off the wire. This is a minor issue that is typically only
relevant in test cases, and will be addressed in the next commit.
This removes a dubious performance "optimization" where strings body
chunks were concatenated to one another (and to the headers) without any
regard for their encoding.
Achieve a minor speed-up by looking up the timeout callback on the timer
object by using an array index rather than a named property.
Gives a performance boost of about 1% on the misc/timers benchmarks.
Code cleanup: don't call a Connection object `p` in some places, `c` in
other places and `ss` in yet other places. Let's just call it `conn`.
This also fixes about a million style errors in one fell swoop.
Don't create an Integer when setting a numeric index on an object or an
array, use the version of v8::Object::Set() that takes an uint32_t.
Change the types of the variables from int to uint32_t and clean up
some code consistency issues while we're here.
Don't set the oncomplete property in src/cares_wrap.cc, we can do it
just as easily in lib/dns.js.
Switch two closures to the 'function with _this_ object' model. Makes
it impossible for an overzealous closure to capture too much context
and accidentally hold on to too much memory.
* The test calls an internal API that changed in commit ca9eb71.
* Trying to reverse-lookup a bogus hostname now returns EINVAL rather
than the (bogus!) status code ENOTIMP.
Use v8::Integer::NewFromUnsigned() when updating the writeQueueSize
field.
Before this commit, it used v8::Integer::New() but that takes an
int32_t. It's unlikely for a write queue to grow beyond 2**31-1 bytes
but let's use the unsigned integer constructor anyway, just in case.
This is [1] applied ahead of time. Summary:
OpenBSD doesn't have <ucontext.h>. ucontext_t lives in <signal.h>
and is a typedef for struct sigcontext. There is no uc_mcontext.
[1] https://codereview.chromium.org/21705003/
Note: the patch has been accepted upstream but hasn't made its way into
a stable release yet.
No one in this day and age should be using SSLv2 so disable it by
default. You can re-enable it with `./configure --with-sslv2` but
there really should be no reason for that.
Alphabetical order should make it easier to find the switches you need
because we've got quite a lot of them now.
Keep --prefix at the top because that's arguably the one people will be
looking for most.
Don't run configure when the configure script has been touched. Doing so
would be okay if the Makefile passed the original arguments to configure
but it doesn't - it runs configure without any arguments, effectively
destroying the current configuration.
Remove this misfeature and instead print an error message telling the
user to (re-)run configure.
Change process.domain to use a getter/setter and access that property
via an array index. These are much faster to get from c++, and it can be
passed to _setupDomainUse and stored as a Persistent<Array>.
InDomain() and GetDomain() as trivial ways to access the domain
information in the native layer. Important because we'll be able to
quickly access if a domain is active. Instead of just whether the domain
module has been loaded.
Don't use v8::Object::SetHiddenValue() to keep a reference alive to the
buffer, we can just as easily do that from JS land and it's a lot faster
to boot.
Because the buffer is now a visible property of the write request
object, it's essential that we do *not* log it - we'd be effectively
serializing the whole buffer to a pretty-printed string.
v0.10 allows strings for the offset, length and port arguments to
dgram.send() and dgram.sendto() but master before this commit would
abort with the following assert:
node: ../../src/udp_wrap.cc:227: static void
node::UDPWrap::DoSend(const v8::FunctionCallbackInfo<v8::Value>&,
int): Assertion `args[2]->IsUint32()' failed.
Go beyond what v0.10 does and also add range checks: offset and length
should be >= 0, port should be between 1 and 65535.
That particular change needs to be back-ported to v0.10 because passing
a negative offset or length number aborts with the following assertions:
node: ../../src/udp_wrap.cc:264: static v8::Handle<v8::Value>
node::UDPWrap::DoSend(const v8::Arguments&, int): Assertion
`offset < Buffer::Length(buffer_obj)' failed.
Or:
node: ../../src/udp_wrap.cc:265: static v8::Handle<v8::Value>
node::UDPWrap::DoSend(const v8::Arguments&, int): Assertion
`length <= Buffer::Length(buffer_obj) - offset' failed.
Interestingly enough, a negative port number is accepted in v0.10 but
is silently ignored.
This commit exposed a bug in the simple/test-dgram-close test which
has also been fixed.
* Change calls to String::New() and String::NewSymbol() to their
respective one-byte, two-byte and UTF-8 counterparts.
* Add a FIXED_ONE_BYTE_STRING macro that takes a string literal and
turns it into a v8::Local<v8::String>.
* Add helper functions that make v8::String::NewFromOneByte() easier to
work with. Said function expects a `const uint8_t*` but almost every
call site deals with `const char*` or `const unsigned char*`. Helps
us avoid doing reinterpret_casts all over the place.
* Code that handles file system paths keeps using UTF-8 for backwards
compatibility reasons. At least now the use of UTF-8 is explicit.
* Remove v8::String::NewSymbol() entirely. Almost all call sites were
effectively minor de-optimizations. If you create a string only once,
there is no point in making it a symbol. If you are create the same
string repeatedly, it should probably be cached in a persistent
handle.
When a stream is flowing, and not in the middle of a sync read, and
the read buffer currently has a length of 0, we can just emit a 'data'
event rather than push it onto the array, emit 'readable', and then
automatically call read().
As it happens, this is quite a frequent occurrence! Making this change
brings the HTTP benchmarks back into a good place after the removal of
the .ondata/.onend socket kludge methods.
smalloc.alloc now accepts an optional third argument which allows
specifying the type of array that should be allocated. All available
types are now located on smalloc.Types.
* Moved the ToObject check out of smalloc::Alloc and into JS. Direct
usage of that method is for internal use only and so can bypass the
possible coercion.
* Same has been done with smalloc::SliceOnto.
* smalloc::CopyOnto will now throw if passed argument is not an object.
* Remove extra TargetFreeCallback function. There was a use for it when
it was working with a Local<T>, but that code has been removed making
the function superfluous.
There are some agent subclasses using this today.
Despite the addRequest function being undocumented internal API, it's
easy enough to just support the old signature for backwards
compatibility.
Add is_named_pipe(), is_named_pipe_ipc() and is_tcp() and update the
code base to use those rather than `stream->type == UV_FOO` and
`reinterpret_cast<uv_pipe_t*>(handle)->ipc` style checks.
Hide member fields behind getters. Make the fields themselves const
in the sense that the pointer is non-assignable - the pointed to object
remains mutable.
Makes reasoning about lifecycle and mutability a little easier.
`server.SNICallback` was initialized with `SNICallback.bind(this)`, and
therefore check `this.SNICallback === SNICallback` was always false, and
`_tls_wrap.js` always thought that it was a custom callback instead of
default one. Which in turn was causing clienthello parser to be enabled
regardless of presence of SNI contexts.
Don't create a superfluous Number object, just use the version of
v8::Object::Get() that takes an unsigned int. Convert the index to
unsigned int while we're here.
If an error listener is added to a stream using once() before it is
piped, it is invoked and removed during pipe() but before pipe() sees it
which causes it to be emitted again.
Fixes#4155#4978
The type of the expression `(uint16_t) server_names_len + 2` gets
implicitly widened to int. Change the type of server_names_len to
uint32_t to avoid the following warnings:
../../src/node_crypto_clienthello.cc:144: warning: comparison
between signed and unsigned integer expressions
../../src/node_crypto_clienthello.cc:146: warning: comparison
between signed and unsigned integer expressions
Quoting the CVE:
Google V8, as used in Google Chrome before 28.0.1500.95, allows
remote attackers to cause a denial of service or possibly have
unspecified other impact via vectors that leverage "type confusion."
Likely has zero impact on node.js because it only runs local, trusted
code but let's apply it anyway.
This is a back-port of upstream commit r15665. Original commit log:
Use internal array as API function cache.
R=yangguo@chromium.org
BUG=chromium:260106
TEST=cctest/test-api/Regress260106
Review URL: https://codereview.chromium.org/19159003Fixes#5973.
Flags and modes aren't the same, symlinks are followed in all of the
path but the last component, docs should say something about what the
mode argument is for and when its used, fs.openSync should point to the
function that contains the docs for its args, as fs.writeSync does.
This is [1] applied ahead of time. Summary:
OpenBSD doesn't have <ucontext.h>. ucontext_t lives in <signal.h>
and is a typedef for struct sigcontext. There is no uc_mcontext.
[1] https://codereview.chromium.org/21705003/
It shouldn't ignore it!
There're two possibile cases, which should be handled properly:
1. Having a default `SNICallback` which is using contexts, added with
`server.addContext(...)` routine
2. Having a custom `SNICallback`.
In first case we may want to opt-out setting `.onsniselect` method (and
thus save some CPU time), if there're no contexts added. But, if custom
`SNICallback` is used, `.onsniselect` should always be set, because
server contexts don't affect it.
Update a few more `Local<T>::New(isolate, persistent)` call sites to
`PersistentToLocal(isolate, persistent)` - the latter has a fast path
for non-weak persistent references.
When doing `FreeEmpty`, `NodeBIO` skips pre-allocated `head_` buffer.
However this might lead to double-freeing buffers since in `~NodeBIO()`
we're starting deallocation from `head_` buffer.
Commit 78d9094 updated src/*.cc to use the version of PersistentToLocal
that takes a v8::Isolate* as its first argument. This commit removes
the non-isolate version.
* Numeric values passed to alloc were converted to int32, not uint32
before the range check, which allows wrap around on ToUint32. This
would cause massive malloc calls and v8 fatal errors.
* dispose would not check if value was an Object, causing segfault if a
Primitive was passed.
* kMaxLength was not enumerable.
Build breakage accidentally introduced in 8e29ce9 during code cleanup.
HAVE_OPENSSL is always defined (as either 0 or 1) so use #if rather
than #ifdef.
Fixes#5979.
Run the garbage collector before running the actual test. It doesn't
matter now but if in the future something in node.js core creates a lot
of reclaimable garbage, that will break the test's expectation.
* Run the garbage collector before creating the big array. It doesn't
matter now but if in the future something in node.js core creates
a lot of reclaimable garbage, that will break the test's expectation.
* The first RSS check was being done too late. The garbage collector
might have run before the check, throwing off the 'reclaimed memory'
calculation.
* Due to changes in how V8 represents the big array internally, the
actual memory usage is just below 256 MB on x64. Update the test's
expectation.
Before this commit, events were set to undefined rather than deleted
from the EventEmitter's backing dictionary for performance reasons:
`delete obj.key` causes a transition of the dictionary's hidden class
and that can be costly.
Unfortunately, that introduces a memory leak when many events are added
and then removed again. The strings containing the event names are never
reclaimed by the garbage collector because they remain part of the
dictionary.
That's why this commit makes EventEmitter delete events again. This
effectively reverts commit 0397223.
Fixes#5970.
Change the build/include_order rule to match our preference:
project headers before system headers.
The rationale is that system headers before project headers makes it
easy to slip in bugs where a project header that requires a definition
from a system header, forgets to include the system header but still
compiles because the source files that include the project header
coincidentally include the system header too.
A good example is the size_t type. A project header file that needs the
definition of size_t should include stddef.h but forgetting to do so
will probably go unnoticed for a long time because almost every other
system header includes stddef.h (either directly or indirectly) and
almost every source file includes one or more system headers.
Ergo, project headers before system headers. It's a good thing.
To prevent all unnecessary calls to JS from MakeCallback, the remaining
two immediate return variables inTick and lastThrew have been added to
infoBox. Now MakeCallback should never need to call into JS unless it
absolutely has to.
Also removed Tock. Performance tests showed it was at least as fast or
faster than using a normal object, and this is more readable.
Avoid a costly buffer-to-string operation. Instead, allocate a new
buffer, copy the chunk header and data into it and send that.
The speed difference is negligible on small payloads but it really
shines with larger (10+ kB) chunks. benchmark/http/end-vs-write-end
with 64 kB chunks gives 45-50% higher throughput. With 1 MB chunks,
the difference is a staggering 590%.
Of course, YMMV will vary with real workloads and networks but this
commit should have a positive impact on CPU and memory consumption.
Big kudos to Wyatt Preul (@wpreul) for reporting the issue and providing
the initial patch.
Fixes#5941 and #5944.
Use the StringBytes::IsValidString() function introduced in commit
dce26cc to ensure that the input string meets the expectations of the
other StringBytes functions before processing it further.
Fixes the following assertion:
Assertion failed: (str->Length() % 2 == 0 && "invalid hex string
length"), function StorageSize, file ../../src/string_bytes.cc,
line 301.
Fixes#5725.
Performs a quick, non-exhaustive check on the input string to see if
it's compatible with the specified string encoding.
Curently it only checks that hex strings have a length that is a
multiple of two.
Don't throw an exception when the argument to %j is an object that
contains circular references, it's not helpful. Catch the exception
and return the string '[Circular]'.
Prior, strings would first be converted to a Buffer before being written
to disk. Now the intermediary step has been removed.
Other changes of note:
* Class member "must_free" was added to req_wrap so to track if the
memory needs to be manually cleaned up after use.
* External String Resource support, so the memory will be used directly
instead of copying out the data.
* Docs have been updated to reflect that if position is not a number
then it will assume null. Previously it specified the argument must be
null, but that was not how the code worked. An attempt was made to
only support == null, but there were too many tests that assumed !=
number would be enough.
* Docs update show some of the write/writeSync arguments are optional.
* Use ARRAY_SIZE() rather than scanning until we hit a NULL entry.
* Fix `-fsigned-char -Wnarrowing` compiler warnings. Harmless but
numerous and annoying.
* Static-ify the modp_group and mod_groups arrays.
* Const-ify the modp_groups array.
It imports the definition into every source file that includes
string_bytes.h, as evidenced by the build suddenly breaking left
and right because of missing Handle/Local/String/Value imports.
Passing the number of sent bytes to the callback is superfluous;
datagram sockets operate in atomic mode: either the sendmsg() system
call succeeds or it fails but it never does partial writes.
Instead, report send errors to the callback. UDP error reporting is
fairly haphazard on most platforms. You should not expect reliable
delivery of anything besides EMSGSIZE and (possibly) ENETDOWN and
ENETUNREACH.
Fixes#2608.
V8 3.20.9 enforces that external pointers are aligned on a two-byte
boundary.
We cannot portably guarantee that for the source code strings that
tools/js2c.py generates so simply stop using String::NewExternal()
altogether (and by extension String::ExternalAsciiStringResource).
Fixes the following run-time assert:
FATAL ERROR: v8::String::NewExternal() Pointer is not aligned
This prevents the following sort of thing from being confusing:
```javascript
stream.on('data', function() { console.error('got data'); });
stream.pause(); // stop reading
// turns out no data is available
stream.push(null);
// Hand the stream to someone else, who does stuff...
setTimeout(function() {
// too late! 'end' is already emitted!
stream.on('end', function() { console.error('got end'); });
});
```
With this change, the `end` event is not emitted until you call `read()`
*past* the EOF null. So, a paused stream will not swallow the `end`
event and emit it before you `resume()` the stream.
The title shouldn't be too long; libuv's uv_set_process_title() out of
security considerations no longer overwrites envp, only argv, so the
maximum title length is possibly quite short.
Fixes#5908.
And process.getgid() too.
Commit ed80638 changed fs.chown() and fs.fchown() to only accept
unsigned integers. Make process.getuid() and process.getgid() follow
suit.
This commit should unbreak npm on OS X - it's hitting the new 'uid must
be an unsigned int' check when installing as e.g. user 'nobody' (which
has an UID of -2 in /etc/passwd or 4294967294 when cast to an uid_t.)
Fixes#5904.
* uv: Upgrade to v0.10.13
* npm: Upgrade to v1.3.5
* os: Don't report negative times in cpu info (Ben Noordhuis)
* fs: Handle large UID and GID (Ben Noordhuis)
* url: Fix edge-case when protocol is non-lowercase (Shuan Wang)
* doc: Streams API Doc Rewrite (isaacs)
* node: call MakeDomainCallback in all domain cases (Trevor Norris)
* crypto: fix memory leak in LoadPKCS12 (Fedor Indutny)
If `obj` given to `cluster._getServer` has `_setServerData` or
`_getServerData` methods, the data will be synchronized across workers
and stored in master.
This incarnation of macros.py is only used to disable the (d)trace
macros. Rename it so it better reflects its purpose. A new macros.py
will be added in a follow-up commit.
Includes:
* No need for `typeof` when checking undefined.
* length is coerced to uint so no need to check if < 0.
* Stay consistent and always throw `new` errors.
* Returning offset + magic number in every write is error prone. Instead
return the central write function which returns the correct offset.
In a rush to implement the fix 35e0d60 I overlooked the logic that
causes 0-length buffer instantiation to automatically not assign the
parent regardless.
Before this commit, fs.chown() and fs.fchown() coerced the uid and gid
arguments to signed integers which is wrong because uid_t and gid_t are
unsigned on most all platforms and IDs that don't fit in a signed
integer do exist.
This commit changes the aforementioned functions to take unsigned ints
instead. No test because we can't assume the system has [GU]IDs that
large.
This change depends on joyent/libuv@d779eb5.
Fixes#5890.
SlowBuffer(0) passes NULL instead of doing malloc(0). So when someone
attempted to SlowBuffer(0).slice(0, 1) an assert would fail in
smalloc::SliceOnto.
It's important that the check go where it is because the resulting
Buffer needs to have external array data allocated. In the case a user
tries to slice a zero length Buffer it will also have NULL passed as the
data argument.
Also fixed where the .parent attribute was set for zero length Buffers.
There is no need to track the source of slice if the slice isn't
actually occurring.
Closes#5860
In streams2, there is an "old mode" for compatibility. Once switched
into this mode, there is no going back.
With this change, there is a "flowing mode" and a "paused mode". If you
add a data listener, then this will start the flow of data. However,
hitting the `pause()` method will switch *back* into a non-flowing mode,
where the `read()` method will pull data out.
Every time `read()` returns a data chunk, it also emits a `data` event.
In this way, a passive data listener can be added, and the stream passed
off to some other reader, for use with progress bars and the like.
There is no API change beyond this added flexibility.
Just forward declare struct sockaddr, the struct is never actually
dereferenced in src/node_internals.h.
Before this commit, it included sys/socket.h but that header doesn't
exist on Windows.
Libuv now returns errors directly. Make everything in src/ and lib/
follow suit.
The changes to lib/ are not strictly necessary but they remove the need
for the abominations that are process._errno and node::SetErrno().
Prep work for removing process._errno. The handle.getsockname() function
will return a status code in the future and set the address and port
properties on the object that's passed in from JS land.
Commit 636ca7c adds an optimization that casts strong Persistent<T>
handles directly to Local<T> handles to avoid the overhead of creating
new HandleScope-rooted Local<T> handles all the time.
One gotcha that I missed is that it's no longer legal to reference the
Local<T> after calling Persistent<T>::Dispose(). This commit addresses
that.
Helps catch bugs early on. Without it, V8 throws the fairly
unhelpful exception "TypeError: undefined is not a function" -
unhelpful because there is no stack trace.
It will be confusing if later on we add Buffer#dispose(), and smalloc is
its own cpp api anyways. So instead create a new require('smalloc') to
expose the previous Buffer.alloc/dispose methods, and expose copyOnto
and kMaxLength as well.
Other changes:
* Added documentation and additional tests.
* smalloc::CopyOnto has changed from using assert() to throwing errors
on bad argument values because it is not exposed to the user.
* Minor style fixes.
When using url.parse(), path and pathname usually return '/' when there
is no path available. However when you have a protocol that contains
non-lowercase letters and the input string does not have a trailing
slash, both path and pathname will be undefined.
The Streams API doc is now broken up into 3 sections:
1. API for Consumers
2. API for Implementors
3. Details and Extras
This addresses one of the biggest points of confusion for new users who
start to consume streams, and get the impression that they have to do
lots of extra work and implement classes and such, just to get some data
out of a file.
In fa10b75 the assert to check if data == NULL was remove for
smalloc::Alloc with no callback. It should have also been removed where
a callback is accepted.
No sense in making sure that length == 0 if data == NULL because devs
already have to be responsible for checking that length is the same as
the char* they're passing in.
It hits a compiler bug in gcc <= 4.4 similar to the issue that was
recently addressed in commit 157d2bc:
../deps/v8/include/v8.h: In function ‘char*
node::Buffer::Data(v8::Persistent&) [with TypeName = v8::Object]’:
../src/node_crypto.cc:1123: instantiated from here
../deps/v8/include/v8.h:876: error: ‘class v8::Data’ is not a
function,
../src/node_internals.h:356: error: conflict with ‘template char*
node::Buffer::Data(v8::Persistent&)’
../src/node_internals.h:357: error: in call to ‘Data’
Remove the helper function, it was only used in a couple of places.
Should fix the build on Ubuntu 10.04.
Fixes#5844.
Previously there was no way to pass a Function callback directly to
MakeCallback and support domains. The check has been added so that users
never have to worry about supporting domains while using MakeCallback.
X509_STORE_add_cert increment reference of passed `x509` cert,
`X509_free` must be called to avoid memory leak.
This is a back-port of commit c1db1ec from the master branch.
* uv: Upgrade to v0.10.12
* npm: Upgrade to 1.3.2
* windows: get proper errno (Ben Noordhuis)
* tls: only wait for finish if we haven't seen it (Timothy J Fontaine)
* http: Dump response when request is aborted (isaacs)
* http: use an unref'd timer to fix delay in exit (Peter Rust)
* zlib: level can be negative (Brian White)
* zlib: allow zero values for level and strategy (Brian White)
* buffer: add comment explaining buffer alignment (Ben Noordhuis)
* string_bytes: properly detect 64bit (Timothy J Fontaine)
* src: fix memory leak in UsingDomains() (Ben Noordhuis)
A pooled https agent may get a Connection: close, but never finish
destroying the socket as the prior request had already emitted finish
likely from a pipe.
Since the socket is not marked as destroyed it may get reused by the
agent pool and result in an ECONNRESET.
re: #5712#5739
Instead of destroying sockets when there are no pending requests, put
them in a freeSockets list, and unref() them so that they do not keep
the event loop open.
Also, set the default max sockets to Infinity, to prevent the awful
surprising deadlocks that happen when more connections are made.
When creating a slice, make sure to propagate the originating parent.
This is to prevent a buf.parent.parent.(etc) scenario.
Also speed up the constructor by preventing lookup of non-existant
properties by setting them beforehand in the prototype. (see
https://github.com/joyent/node/commit/7ce5a31#commitcomment-3332779)
Since the SlabAllocator was removed the buffer length/offset is no
longer sent to the onread callback. The benchmarks have been updated to
reflect that.
Fix bug where if dev passed a callback to Alloc then called AllocDispose
it wouldn't bother to pass the data to the callback and instead would
just free it.
There was previously up to a second exit delay when exiting node
right after an http request/response, due to the utcDate() function
doing a setTimeout to update the cached date/time.
Fixing this should increase the performance of our http tests.
This is a big commit that touches just about every file in the src/
directory. The V8 API has changed in significant ways. The most
important changes are:
* Binding functions take a const v8::FunctionCallbackInfo<T>& argument
rather than a const v8::Arguments& argument.
* Binding functions return void rather than v8::Handle<v8::Value>. The
return value is returned with the args.GetReturnValue().Set() family
of functions.
* v8::Persistent<T> no longer derives from v8::Handle<T> and no longer
allows you to directly dereference the object that the persistent
handle points to. This means that the common pattern of caching
oft-used JS values in a persistent handle no longer quite works,
you first need to reconstruct a v8::Local<T> from the persistent
handle with the Local<T>::New(isolate, persistent) factory method.
A handful of (internal) convenience classes and functions have been
added to make dealing with the new API a little easier.
The most visible one is node::Cached<T>, which wraps a v8::Persistent<T>
with some template sugar. It can hold arbitrary types but so far it's
exclusively used for v8::Strings (which was by far the most commonly
cached handle type.)
The previous commit removes our patch that builds V8 at -O2 rather
than -O3 so there is not much point in keeping the configure switch
around.
The reason it did so was to work around an assortment of compiler and
linker bugs. In particular, certain combinations of g++ and binutils
generate bad or no code when -ffunction-sections or -finline-functions
is enabled (which -O3 implicitly does.)
It was quite the problem back in the day because everyone and his dog
built from source. Now that we have prebuilt binaries and packages
available, there is no longer a pressing need to be so accommodating.
If you experience spurious (or possibly not so spurious) segmentation
faults after this commit, you need to upgrade your compiler/linker
toolchain.
UsingDomains() assigned process_tickCallback when it had already
been set by MakeCallback() a few frames down the call stack.
Dispose the handle first or we'll retain whatever is in the lexical
closure of the old process._tickCallback function.
Fixes#5795.
If a transform stream has objectMode = true, it should
allow falsey values other than (null) like 0, false, ''.
null is reserved to indicate stream eof but other falsey
values should flow through properly.
Now that Buffer instantiation has improved, the SlabAllocator is an
unnecessary layer of complexity preventing further performance
optimizations.
Currently there is a small performance loss with very small stream
requests, but this will soon be addressed.
Assert that when the client closes it has seen an error, this prevents
the test from timing out.
Also queue a second write in the case that we were able to send the
buffer before the other side closed the connection.
There was previously up to a second exit delay when exiting node
right after an http request/response, due to the utcDate() function
doing a setTimeout to update the cached date/time.
Fixing this should increase the performance of our http tests.
Assert that when the client closes it has seen an error, this prevents
the test from timing out.
Also queue a second write in the case that we were able to send the
buffer before the other side closed the connection.
Most TryCatch blocks have SetVerbose flag on, this tells V8 to report
uncaught exceptions to debugger.
FatalException handler is called from V8 Message listener instead from
the place where TryCatch was used. Otherwise uncaught exceptions are
logged twice.
See comment in `deps/v8/include/v8.h` for explanation of SetVerbose
flag:
> By default, exceptions that are caught by an external exception
> handler are not reported. Call SetVerbose with true on an
> external exception handler to have exceptions caught by the
> handler reported as if they were not caught.
The flag is used by `Isolate::ShouldReportException()`, which is called
by `Isolate::DoThrow()` to decide whether an exception is considered
uncaught.
Might cause write head running over read head, when there were no
allocation and `Commit()` was called. Source of at least one test
failure on windows (`simple/test-https-drain.js`).
gcc 4.2 on OS X gets confused about the call to node::Buffer::Data().
Fully qualify the function name to help it along.
Fixes the following build error:
../../deps/v8/include/v8.h: In function ‘char*
node::Buffer::Data(v8::Handle<v8::Value>)’:
../../deps/v8/include/v8.h:900: error: ‘class v8::Data’
is not a function,
../../src/node_buffer.h:38: error:
conflict with ‘char* node::Buffer::Data(v8::Handle<v8::Object>)’
../../src/node_buffer.cc:94: error:
in call to ‘Data’
Buffer(<String>) used to pass the string to js where it would then be
passed back to cpp for processing. Now only the buffer object
instantiation is done in js and the string is processed in cpp.
Also added a Buffer api that also accepts the encoding.
Old fill would take the char code of the first character and wrap around
the int to fit in the 127 range. Now fill will duplicate whatever string
is given through the entirety of the buffer.
Note: There is one bug around ending on a partial fill of any character
outside the ASCII range.
While the new Buffer implementation is much faster we still have the
necessity of using Buffer pools. This is undesirable because it may
still lead to unwanted memory retention, but for the time being this is
the best solution.
Because of this re-introduction, and since there is no more SlowBuffer
type, the SlowBuffer method has been re-purposed to return a non-pooled
Buffer instance. This will be helpful for developers to store data for
indeterminate lengths of time without introducing a memory leak.
Another change to Buffer pools was that they are only allocated if the
requested chunk is < poolSize / 2. This was done because allocations are
much quicker now, and it's a better use of the pool.
Memory allocations are now done through smalloc. The Buffer cc class has
been removed completely, but for backwards compatibility have left the
namespace as Buffer.
The .parent attribute is only set if the Buffer is a slice of an
allocation. Which is then set to the alloc object (not a Buffer).
The .offset attribute is now a ReadOnly set to 0, for backwards
compatibility. I'd like to remove it in the future (pre v1.0).
A few alterations have been made to how arguments are either coerced or
thrown. All primitives will now be coerced to their respective values,
and (most) all out of range index requests will throw.
The indexes that are coerced were left for backwards compatibility. For
example: Buffer slice operates more like Array slice, and coerces
instead of throwing out of range indexes. This may change in the future.
The reason for wanting to throw for out of range indexes is because
giving js access to raw memory has high potential risk. To mitigate that
it's easier to make sure the developer is always quickly alerted to the
fact that their code is attempting to access beyond memory bounds.
Because SlowBuffer will be deprecated, and simply returns a new Buffer
instance, all tests on SlowBuffer have been removed.
Heapdumps will now show usage under "smalloc" instead of "Buffer".
ParseArrayIndex was added to node_internals to support proper uint
argument checking/coercion for external array data indexes.
SlabAllocator had to be updated since handle_ no longer exists.
If the user knows the allocation is no longer needed then the memory can
be manually released.
Currently this will not ClearWeak the Persistent, so the callback will
still run.
If the user passed a ClearWeak callback, and then disposed the object,
the buffer callback argument will == NULL.
smalloc is a simple utility for quickly allocating external memory onto
js objects. This will be used to centralize how memory is managed in
node, and will become the backer for Buffers. So in the future crypto's
SlabBuffer, stream's SlabAllocator will be removed.
Note on the js API: because no arguments are optional the order of
arguments have been placed to match their cc counterparts as closely as
possible.
The console module has always been called 'stdio' in the
table-of-contents, but nowhere else, since its name is
'console'. This makes it difficult to find.
This is a back-port of commit 226a20d from the master branch.
Libuv may provide a NULL buffer to the uv_read callback in case of an
error, so with this assert we'd be using the api incorrectly. None of
the current DoRead implementations rely on this constraint, either.
The console module has always been called 'stdio' in the
table-of-contents, but nowhere else, since its name is
'console'. This makes it difficult to find.
Resolves minor discrepancies between android and standard POSIX systems.
In addition, some configure parameters were added, and a helper-script
for android configuration. Ideally, this script should be merged into
the standard configure script.
To build for android, source the android-configure script with an NDK
path:
source ./android-configure ~/android-ndk-r8d
This will create an android standalone toolchain and export the
necessary environment parameters.
After that, build as normal:
make -j8
After the build, you should now have android-compatible NodeJS binaries.
Suppress the following warning:
../../src/cares_wrap.cc: In function ‘v8::Handle<v8::Value>
node::cares_wrap::SetServers(const v8::Arguments&)’:
../../src/cares_wrap.cc:1017:5: warning: ‘uv_ret.uv_err_s::code’
may be used uninitialized in this function [-Wuninitialized]
Split `tls.js` into `_tls_legacy.js`, containing legacy
`createSecurePair` API, and `_tls_wrap.js` containing new code based on
`tls_wrap` binding.
Remove tests that are no longer useful/valid.
In case of cross-compilation host_arch_cc() function could return
target arch if CC was set to target arch compiler. Host arch
compiler should always be used in this case. This was broken
by commit 707863c.
This reverts commit a40133d10c.
Unfortunately, this breaks socket.io. Even though it's not strictly an
API change, it is too subtle and in too brittle an area of node, to be
done in a stable branch.
Conflicts:
doc/api/http.markdown
When large strings are used they cause v8's GC to spend a lot more time
cleaning up. In these cases it's much faster to use external string
resources.
UTF8 strings do not use external string resources because only one and
two byte external strings are supported.
EXTERN_APEX is the value at which v8's GC overtakes performance.
The following table has the type and buffer size that use to encode the
strings as rough estimates of the percentage of performance gain from
this patch (UTF8 is missing because they cannot be externalized).
encoding 128KB 1MB 5MB
-----------------------------
ASCII 58% 208% 250%
HEX 15% 74% 86%
BASE64 11% 74% 71%
UCS2 2% 225% 398%
BINARY 2234% 1728% 2305%
BINARY is so much faster across the board because of using the new v8
WriteOneByte API.
v8 has a new API to write out strings to memory. This has been
implemented.
One other change of note is BINARY encoded strings have a new
implementation. This has improved performance substantially.
Clang branch release_33 would optimize out a != NULL check because of
some undefined behavior. This is a floating patch as a backport of that
fix.
Committed: http://code.google.com/p/v8/source/detail?r=13570
Normalize the encoding in getEncoding() before using it. Fixes a
"AssertionError: Cannot change encoding" exception when the caller
mixes "utf8" and "utf-8".
Fixes#5655.
Before this commit NodeBIO never shrank, possibly consuming a lot of
memory (depending on reader's haste).
All buffers between write_head's child and read_head should be
deallocated on read, leaving only space left in write_head and in the
next buffer.
Commit 0bba5902 accidentally (or maybe erroneously) added node_isolate
to src/node.h and src/node_object_wrap.h.
Undo that, said variable is not for public consumption. Add-on authors
should use v8::Isolate::GetCurrent() instead.
I missed that while reviewing. Mea culpa.
Fixes#5639.
This is only relevant for CentOS 6.3 using kernel version 2.6.32.
On other linuxes and darwin, the `read` call gets an ECONNRESET in that
case. On sunos, the `write` call fails with EPIPE.
However, old CentOS will occasionally send an EOF instead of a
ECONNRESET or EPIPE when the client has been destroyed abruptly.
Make sure we don't keep trying to write or read more in that case.
Fixes#5504
However, there is still the question of what libuv should do when it
gets an EOF. Apparently in this case, it will continue trying to read,
which is almost certainly the wrong thing to do.
That should be fixed in libuv, even though this works around the issue.
In cases where there are multiple @-chars in a url, Node currently
parses the hostname and auth sections differently than web browsers.
This part of the bug is serious, and should be landed in v0.10, and
also ported to v0.8, and releases made as soon as possible.
The less serious issue is that there are many other sorts of malformed
urls which Node either accepts when it should reject, or interprets
differently than web browsers. For example, `http://a.com*foo` is
interpreted by Node like `http://a.com/*foo` when web browsers treat
this as `http://a.com%3Bfoo/`.
In general, *only* the `hostEndingChars` should be the characters that
delimit the host portion of the URL. Most of the current `nonHostChars`
that appear in the hostname should be escaped, but some of them (such as
`;` and `%` when it does not introduce a hex pair) should raise an
error.
We need to have a broader discussion about whether it's best to throw in
these cases, and potentially break extant programs, or return an object
that has every field set to `null` so that any attempt to read the
hostname/auth/etc. will appear to be empty.
In some cases, the http CONNECT/Upgrade API is unshifting an empty
bodyHead buffer onto the socket.
Normally, stream.unshift(chunk) does not set state.reading=false.
However, this check was not being done for the case when the chunk was
empty (either `''` or `Buffer(0)`), and as a result, it was causing the
socket to think that a read had completed, and to stop providing data.
This bug is not limited to http or web sockets, but rather would affect
any parser that unshifts data back onto the source stream without being
very careful to never unshift an empty chunk. Since the intent of
unshift is to *not* change the state.reading property, this is a bug.
Fixes#5557FixesLearnBoost/socket.io#1242
Remove the need to call start/stop the uv_idle spinner between
MakeCallbacks. The one place where the tick processor needs to be kicked
is where a user catches uncaughtException. For that we'll now use
setImmediate, which accomplishes the same task.
maxTickDepth checks have been removed for domains and replaced with a
flag that checks if the last callback threw. If it did then execution of
the remaining tickQueue is deferred to the spinner.
This is to prevent domains from entering a continuous loop when an error
callback also throws an error.
Removes the check for maxTickDepth for non-domain callbacks. So a user
can starve I/O by setting a recursive nextTick.
The domain case is more complex and will be addressed in another commit.
Previous code was calling uv_loop_delete() directly on a running loop,
which led to race condition aborts/segfaults within libuv. This change
changes the watchdog thread to call uv_run() with UV_RUN_ONCE so that
the call exits after either the timer times out or uv_async_send() is
called from the main thread in Watchdog::Destroy(). The timer/async
handles are then closed and uv_run() with UV_RUN_DEFAULT is called so
that libuv has a chance to cleanup before the thread exits. The main
thread meanwhile calls uv_thread_join() and then uv_loop_delete() to
complete the cleanup.
Before this, entering something like:
> JSON.parse('066');
resulted in the "..." prompt instead of displaying the expected
"SyntaxError: Unexpected number"
1. Emit `sslOutEnd` only when `_internallyPendingBytes() === 0`.
2. Read before checking `._halfRead`, otherwise we'll see only previous
value, and will invoke `._write` callback improperly.
3. Wait for both `end` and `finish` events in `.destroySoon`.
4. Unpipe encrypted stream from socket to prevent write after destroy.
Stream's `._write()` callback should be invoked only after it's opposite
stream has finished processing incoming data, otherwise `finish` event
fires too early and connection might be closed while there's some data
to send to the client.
see #5544
Quote from SSL_shutdown man page:
The output of SSL_get_error(3) may be misleading,
as an erroneous SSL_ERROR_SYSCALL may be flagged even though
no error occurred.
Also, handle all other errors to prevent assertion in `ClearError()`.
When writing bad data to EncryptedStream it'll first get to the
ClientHello parser, and, only after it will refuse it, to the OpenSSL.
But ClientHello parser has limited buffer and therefore write could
return `bytes_written` < `incoming_bytes`, which is not the case when
working with OpenSSL.
After such errors ClientHello parser disables itself and will
pass-through all data to the OpenSSL. So just trying to write data one
more time will throw the rest into OpenSSL and let it handle it.
Otherwise, writing an empty string causes the whole program to grind to
a halt when piping data into http messages.
This wasn't as much of a problem (though it WAS a bug) in 0.8 and
before, because our hyperactive 'drain' behavior would mean that some
*previous* write() would probably have a pending drain event, and cause
things to start moving again.
This saves a few calls to gettimeofday which can be expensive, and
potentially subject to clock drift. Instead use the loop time which
uses hrtime internally.
fixes#5497
This commit adds an optimization to the HTTP client that makes it
possible to:
* Pack the headers and the first chunk of the request body into a
single write().
* Pack the chunk header and the chunk itself into a single write().
Because only one write() system call is issued instead of several,
the chances of data ending up in a single TCP packet are phenomenally
higher: the benchmark with `type=buf size=32` jumps from 50 req/s to
7,500 req/s, a 150-fold increase.
This commit removes the check from e4b716ef that pushes binary encoded
strings into the slow path. The commit log mentions that:
We were assuming that any string can be concatenated safely to
CRLF. However, for hex, base64, or binary encoded writes, this
is not the case, and results in sending the incorrect response.
For hex and base64 strings that's certainly true but binary strings
are 'das Ding an sich': string.length is the same before and after
decoding.
Fixes#5528.
Consider a user on his Mac, who wants to cross-compile for his Linux ARM device:
./configure --dest-cpu=arm --dest-os=linux
Before this patch, for example, DTrace probes would incorrectly attempt to be
enabled because the configure script is running on a MacOS machine, even though
we're trying to compile a binary for `linux`.
With this patch, the `--dest-os` flag is respected throughout the configure
script, thus leaving DTrace probes disabled in this cross-compiling scenario.
When an internal api needs a timeout, they should use
timers._unrefActive since that won't hold the loop open. This solves
the problem where you might have unref'd the socket handle but the
timeout for the socket was still active.
Previously one could write anywhere in a buffer pool if they accidently
got their offset wrong. Mainly because the cc level checks only test
against the parent slow buffer and not against the js object properties.
So now we check to make sure values won't go beyond bounds without
letting the dev know.
Because of variations in different base64 implementation, it's been
decided to strip all padding from the end of a base64 string and
calculate its size from that.
Add localAddress and localPort properties to tls.CleartextStream.
Like remoteAddress and localPort, delegate to the backing net.Socket
object.
Refs #5502.
Instead of String::New every time, use a Persistent sym. This can be
accomplished in two ways:
1) Local<String> str = *persistent_str_sym;
2) Handle<String> str = persistent_str_sym;
I've chosen to use the latter method for simplicity's sake.
Other small changes include creating syms on Initialize and removing
unnecessary Local casting on return values.
The default encoding is 'buffer'. When the input is a string, treat it
as 'binary'. Fixes the following assertion:
node: ../src/string_bytes.cc:309: static size_t
node::StringBytes::StorageSize(v8::Handle<v8::Value>, node::encoding):
Assertion `0 && "buffer encoding specified but string provided"'
failed.
Introduced in 64fc34b2.
Fixes#5482.
Test case:
var t = setInterval(function() {}, 1);
process.nextTick(t.unref);
Output:
Assertion failed: (args.Holder()->InternalFieldCount() > 0),
function Unref, file ../src/handle_wrap.cc, line 78.
setInterval() returns a binding layer object. Make it stop doing that,
wrap the raw process.binding('timer_wrap').Timer object in a Timeout
object.
Fixes#4261.
Commit 38149bb changes http.get() and http.request() to escape unsafe
characters. However, that creates an incompatibility with v0.10 that
is difficult to work around: if you escape the path manually, then in
v0.11 it gets escaped twice. Change lib/http.js so it no longer tries
to fix up bad request paths, simply reject them with an exception.
The actual check is rather basic right now. The full check for illegal
characters is difficult to implement efficiently because it requires a
few characters of lookahead. That's why it currently only checks for
spaces because those are guaranteed to create an invalid request.
Fixes#5474.
This also templatizes the Buffer::*Slice functions, and the template
function probably cannot be safely used outside of Node. However, it
also SHOULD not be used outside of Node, so this is arguably a feature
as well as a caveat.
Pretty much everything assumes strings to be utf-8, but crypto
traditionally used binary strings, so we need to keep the default
that way until most users get off of that pattern.
If there is an encoding, and we do 'stream.push(chunk, enc)', and the
encoding argument matches the stated encoding, then we're converting from
a string, to a buffer, and then back to a string. Of course, this is a
completely pointless bit of work, so it's best to avoid it when we know
that we can do so safely.
1. Get the author email with `npm owner ls <pkgname>`
2. Email the author, CC <i@izs.me>.
3. After a few weeks, if there's no resolution, we'll sort it out.
Don't squat on package names. Publish code or move out of the way.
## DESCRIPTION
There sometimes arise cases where a user publishes a module, and then
later, some other user wants to use that name. Here are some common
ways that happens (each of these is based on actual events.)
1. Joe writes a JavaScript module `foo`, which is not node-specific.
Joe doesn't use node at all. Bob wants to use `foo` in node, so he
wraps it in an npm module. Some time later, Joe starts using node,
and wants to take over management of his program.
2. Bob writes an npm module `foo`, and publishes it. Perhaps much
later, Joe finds a bug in `foo`, and fixes it. He sends a pull
request to Bob, but Bob doesn't have the time to deal with it,
because he has a new job and a new baby and is focused on his new
erlang project, and kind of not involved with node any more. Joe
would like to publish a new `foo`, but can't, because the name is
taken.
3. Bob writes a 10-line flow-control library, and calls it `foo`, and
publishes it to the npm registry. Being a simple little thing, it
never really has to be updated. Joe works for Foo Inc, the makers
of the critically acclaimed and widely-marketed `foo` JavaScript
toolkit framework. They publish it to npm as `foojs`, but people are
routinely confused when `npm install foo` is some different thing.
4. Bob writes a parser for the widely-known `foo` file format, because
he needs it for work. Then, he gets a new job, and never updates the
prototype. Later on, Joe writes a much more complete `foo` parser,
but can't publish, because Bob's `foo` is in the way.
The validity of Joe's claim in each situation can be debated. However,
Joe's appropriate course of action in each case is the same.
1.`npm owner ls foo`. This will tell Joe the email address of the
owner (Bob).
2. Joe emails Bob, explaining the situation **as respectfully as possible**,
and what he would like to do with the module name. He adds
isaacs <i@izs.me> to the CC list of the email. Mention in the email
that Bob can run `npm owner add joe foo` to add Joe as an owner of
the `foo` package.
3. After a reasonable amount of time, if Bob has not responded, or if
Bob and Joe can't come to any sort of resolution, email isaacs
<i@izs.me> and we'll sort it out. ("Reasonable" is usually about 4
weeks, but extra time is allowed around common holidays.)
## REASONING
In almost every case so far, the parties involved have been able to reach
an amicable resolution without any major intervention. Most people
really do want to be reasonable, and are probably not even aware that
they're in your way.
Module ecosystems are most vibrant and powerful when they are as
self-directed as possible. If an admin one day deletes something you
had worked on, then that is going to make most people quite upset,
regardless of the justification. When humans solve their problems by
talking to other humans with respect, everyone has the chance to end up
feeling good about the interaction.
## EXCEPTIONS
Some things are not allowed, and will be removed without discussion if
they are brought to the attention of the npm registry admins, including
but not limited to:
1. Malware (that is, a package designed to exploit or harm the machine on
which it is installed).
2. Violations of copyright or licenses (for example, cloning an
MIT-licensed program, and then removing or changing the copyright and
license statement).
3. Illegal content.
4. "Squatting" on a package name that you *plan* to use, but aren't
actually using. Sorry, I don't care how great the name is, or how
perfect a fit it is for the thing that someday might happen. If
someone wants to use it today, and you're just taking up space with
an empty tarball, you're going to be evicted.
5. Putting empty packages in the registry. Packages must have SOME
functionality. It can be silly, but it can't be *nothing*. (See
also: squatting.)
6. Doing weird things with the registry, like using it as your own
personal application database or otherwise putting non-packagey
things into it.
If you see bad behavior like this, please report it right away.
## SEE ALSO
* npm-registry(1)
* npm-owner(1)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
