As RFC 2616 says we should, assume that servers will provide a persistent
connection by default.
> A significant difference between HTTP/1.1 and earlier versions of
> HTTP is that persistent connections are the default behavior of any
> HTTP connection. That is, unless otherwise indicated, the client
> SHOULD assume that the server will maintain a persistent connection,
> even after error responses from the server.
> HTTP/1.1 applications that do not support persistent connections MUST
> include the "close" connection option in every message.
Fixes#2436.
uncaughtException handlers installed by the user override the default one that
the cluster module installs, the one that kills off the master process.
Fixes#2556.
Passing a non-buffer or non-string argument to Socket.prototype.write triggered
an assert:
Assertion failed: (Buffer::HasInstance(args[0])), function Write,
file ../src/stream_wrap.cc, line 289.
Fixes#2532.
- Save StringPtr if the header hasn't been completely received yet after one
packet.
- Add one to num_fields and num_values. They were actually one less than the
number of fields and values.
- Remove always_inline makes debugging difficult, and has negligible
performance benefits.
This makes it so that the stdin TTY-wrap stream gets ref'ed on
.resume() and unref'ed on .pause()
The semantics of the names "pause" and "resume" are a bit weird, but the
important thing is that this corrects an API change from 0.4 -> 0.6
which made it impossible to read from stdin multiple times, without
knowing when it might end up being closed. If no one has it open, this
lets the process die naturally.
LGTM'd by @ry
Don't allow `socket.destroy()` to run twice. The self-destruct sequence itself
is idempotent but it makes the 'close' and 'error' events fire more than once,
which may confuse listeners.
Fixes#2223.