blog: Release v0.8.25

blog: Release 0.10.11

Now working on 0.10.12

Merge branch 'v0.10.11-release' into v0.10

2013.06.13, Version 0.10.11 (Stable)

* uv: upgrade to 0.10.11

* npm: Upgrade to 1.2.30

* openssl: add missing configuration pieces for MIPS (Andrei Sedoi)

* Revert "http: remove bodyHead from 'upgrade' events" (isaacs)

* v8: fix pointer arithmetic undefined behavior (Trevor Norris)

* crypto: fix utf8/utf-8 encoding check (Ben Noordhuis)

* net: Fix busy loop on POLLERR|POLLHUP on older linux kernels (Ben Noordhuis, isaacs)

test: minor typo fixes

openssl: add missing configuration pieces for MIPS

Revert "http: remove bodyHead from 'upgrade' events"

This reverts commit a40133d10cdb911b27fe8d46d67a835b0103bbf1.

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

uv: upgrade to 0.10.11

npm: Upgrade to 1.2.30

v8: fix pointer arithmetic undefined behavior

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

crypto: fix utf8/utf-8 encoding check

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.

build: add pkgsrc rule

npm: Upgrade to 1.2.27

net: Destroy when not readable and not writable

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.

Now working on v0.10.11

blog: Release v0.10.10

Merge branch 'v0.10.10-release' into v0.10

2013.06.04, Version 0.10.10 (Stable)

* uv: Upgrade to 0.10.10

* npm: Upgrade to 1.2.25

* url: Properly parse certain oddly formed urls (isaacs)

* stream: unshift('') is a noop (isaacs)

uv: Upgrade to 0.10.10

url: remove unused global variable

npm: Upgrade to 1.2.25

doc: ChangeLog update for v0.8.24

blog: 0.8 is maintenace, not stable

blog: Release v0.8.24

blog: Release v0.10.9

url: Set href to null by default

url: Properly parse certain oddly formed urls

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.

stream: unshift('') is a noop

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 #5557
Fixes LearnBoost/socket.io#1242

Now working on v0.10.10

Merge branch 'v0.10.9-release' into v0.10

2013.05.30, Version 0.10.9 (Stable)

* npm: Upgrade to 1.2.24

* uv: Upgrade to v0.10.9

* repl: fix JSON.parse error check (Brian White)

* tls: proper .destroySoon (Fedor Indutny)

* tls: invoke write cb only after opposite read end (Fedor Indutny)

* tls: ignore .shutdown() syscall error (Fedor Indutny)

npm: Upgrade to 1.2.24

doc: remove `bufferSize` option

`bufferSize` option has been removed in b0f6789.

repl: fix JSON.parse error check

Before this, entering something like:

> JSON.parse('066');

resulted in the "..." prompt instead of displaying the expected
"SyntaxError: Unexpected number"

tls: proper .destroySoon

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.

doc: sending dgram handles only works on unix

https: Add `secureProtocol` docs

Add `secureProtocol` parameter docs to the https.request method.

tls: Add `secureProtocol` docs

Add `secureProtocol` parameter docs to the tls.connect method.

uv: Upgrade to v0.10.9

tls: invoke write cb only after opposite read end

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

tls: ignore .shutdown() syscall error

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()`.

doc: add link to Brazilian Node community

Add a link to the Brazilian community portal.

doc: remove broken links on community page

Links to Node Manual and Node Bits both are broken, so this commit
removes them from the community page.

blog: Post for v0.10.8

Now working on 0.10.9

Merge branch 'v0.10.8-release' into v0.10

2013.05.24, Version 0.10.8 (Stable)

* v8: update to 3.14.5.9

* uv: upgrade to 0.10.8

* npm: Upgrade to 1.2.23

* http: remove bodyHead from 'upgrade' events (Nathan Zadoks)

* http: Return true on empty writes, not false (isaacs)

* http: save roundtrips, convert buffers to strings (Ben Noordhuis)

* configure: respect the --dest-os flag consistently (Nathan Rajlich)

* buffer: throw when writing beyond buffer (Trevor Norris)

* crypto: Clear error after DiffieHellman key errors (isaacs)

* string_bytes: strip padding from base64 strings (Trevor Norris)

doc: Minor fixup in http doc re bodyHead

tls: retry writing after hello parse error

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.

npm: Upgrade to 1.2.23

uv: upgrade to 0.10.8

http: remove bodyHead from 'upgrade' events

Streams2 makes this unnecessary.
An empty buffer is provided for compatibility.

buffer: special case empty string writes

Prior to 119354f we specifically handled passing a zero length string
to write on a buffer, restore that functionality.

http: Return true on empty writes, not false

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.

v8: re-apply floating patches

v8: fix GetLocalizedMessage usage

As is the backport of the abort on uncaught exception wouldn't compile
because we it was passing in `this` when it was unnecessary.

v8: update to 3.14.5.9

http: save roundtrips, convert buffers to strings

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.

doc: the build requires gcc 4.2 or newer

configure: respect the --dest-os flag consistently

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.

net: use timers._unrefActive for internal timeouts

timers: internal unref'd timer for api timeouts

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.

buffer: throw when writing beyond buffer

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.

crypto: Clear error after DiffieHellman key errors

Fixes #5499

string_bytes: strip padding from base64 strings

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.

src: Remove superfluous static_cast

blog: Release 0.10.7

Now working on 0.10.8

Merge branch 'v0.10.7-release' into v0.10

2013.05.17, Version 0.10.7 (Stable)

* uv: upgrade to v0.10.7

* npm: Upgrade to 1.2.21

* crypto: Don't ignore verify encoding argument (isaacs)

* buffer, crypto: fix default encoding regression (Ben Noordhuis)

* timers: fix setInterval() assert (Ben Noordhuis)

doc: Fix link to open issues on GitHub.

crypto: Don't ignore verify encoding argument

buffer, crypto: fix default encoding regression

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.

doc: fix missing Class in header

doc: fix the link to Stream document

timers: fix setInterval() assert

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.

doc: improve exports/module.exports consistency

While they reference the same object, they are only interchangeable
for updates, not assignment.

doc: clarify exports and module.exports

When exporting a single function you must use `module.exports` instead
of the `exports` convenience reference.

uv: upgrade to v0.10.7

uv: Upgrade to 0.10.6

npm: Upgrade to 1.2.21

blog: Release 0.10.6

Now working on v0.10.7

Merge branch 'v0.10.6-release' into v0.10

crypto: Pass encodings for Hmac digest

2013.05.14, Version 0.10.6 (Stable)

* module: Deprecate require.extensions (isaacs)

* stream: make Readable.wrap support objectMode, empty streams (Daniel Moore)

* child_process: fix handle delivery (Ben Noordhuis)

* crypto: Fix performance regression (isaacs)

* src: DRY string encoding/decoding (isaacs)

crypto: Pass encodings to C++ for Sign/Verify

crypto: use StringBytes::Encode

crypto: Pass strings to binding layer directly

buffer: DRY string encoding using StringBytes

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.

src: use StringBytes for DecodeWrite/DecodeBytes/Encode

Bonus: this makes node::Encode actually work properly with base64,
ucs2, hex, etc.

src: Use StringBytes in StreamWrap

src: Add StringBytes static util class

Four functions:

- StringBytes::StorageSize()
- StringBytes::Size()
- StringBytes::Write()
- StringBytes::Encode()

tools: remove unnecessary cpplint rules

We don't actually care about header order much, and since we never use
stl classes, 'string' isn't an issue for node ever.

stream: Make default encoding configurable

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.

stream: don't create unnecessary buffers in Readable

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.

lint

benchmark: hash stream

blog: Release v0.11.2