Permalink
Commits on May 30, 2013
  1. 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)
    isaacs committed May 30, 2013
  2. npm: Upgrade to 1.2.24

    isaacs committed May 30, 2013
  3. doc: remove `bufferSize` option

    `bufferSize` option has been removed in b0f6789.
    kysnm committed with bnoordhuis May 22, 2013
  4. 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"
    mscdex committed with bnoordhuis May 26, 2013
  5. 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.
    indutny committed May 30, 2013
Commits on May 29, 2013
Commits on May 28, 2013
  1. https: Add `secureProtocol` docs

    Add `secureProtocol` parameter docs to the https.request method.
    danielgtaylor committed with bnoordhuis May 15, 2013
  2. tls: Add `secureProtocol` docs

    Add `secureProtocol` parameter docs to the tls.connect method.
    danielgtaylor committed with bnoordhuis May 15, 2013
  3. uv: Upgrade to v0.10.9

    isaacs committed May 28, 2013
  4. 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
    indutny committed May 27, 2013
  5. 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()`.
    indutny committed May 28, 2013
Commits on May 25, 2013
  1. doc: add link to Brazilian Node community

    Add a link to the Brazilian community portal.
    rafadev7 committed with bnoordhuis May 25, 2013
  2. 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.
    rafadev7 committed with bnoordhuis May 25, 2013
Commits on May 24, 2013
  1. blog: Post for v0.10.8

    isaacs committed May 24, 2013
  2. Now working on 0.10.9

    isaacs committed May 24, 2013
  3. 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)
    isaacs committed May 24, 2013
  4. 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.
    indutny committed with isaacs May 24, 2013
  5. npm: Upgrade to 1.2.23

    isaacs committed May 24, 2013
  6. uv: upgrade to 0.10.8

    isaacs committed May 24, 2013
  7. http: remove bodyHead from 'upgrade' events

    Streams2 makes this unnecessary.
    An empty buffer is provided for compatibility.
    nathan7 committed with isaacs May 24, 2013
Commits on May 23, 2013
  1. 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.
    tjfontaine committed May 23, 2013
  2. 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.
    isaacs committed May 23, 2013
  3. 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.
    tjfontaine committed May 23, 2013
  4. v8: update to 3.14.5.9

    tjfontaine committed May 23, 2013
  5. 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 e4b716e 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.
    bnoordhuis committed May 22, 2013
Commits on May 22, 2013
  1. 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.
    TooTallNate committed May 21, 2013
Commits on May 21, 2013
  1. 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.
    tjfontaine committed May 17, 2013
Commits on May 20, 2013
  1. 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.
    trevnorris committed May 20, 2013
  2. 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.
    trevnorris committed May 20, 2013