diff options
author | isaacs <i@izs.me> | 2013-03-20 16:14:36 -0700 |
---|---|---|
committer | isaacs <i@izs.me> | 2013-03-20 16:14:39 -0700 |
commit | 008ab12b7facea8ac4a718894044963e3b4ee901 (patch) | |
tree | 702face0fabe9c87f079dd639994570ba3219800 | |
parent | 31314b697874eabe2308bd26b98b72aff3e13ef6 (diff) | |
download | node-new-008ab12b7facea8ac4a718894044963e3b4ee901.tar.gz |
tls: Prevent hang in readStart
This is not a great fix, and it's a bug that's very tricky to reproduce.
Occasionally, while downloading a file, especially on Linux for some
reason, the pause/resume timing will be just right such that the
CryptoStream is in a 'reading' state, but actually has no data, so it
ought to pull more in. Because there's no reads happening, it just sits
there, and the process will exit
This is, fundamentally, a factor of how the HTTP implementation sits
atop CryptoStreams and TCP Socket objects, which is utterly horrible,
and needs to be rewritten. However, in the meantime, npm downloads are
prematurely exiting, causing hard-to-debug "cb() never called!" errors.
-rw-r--r-- | lib/tls.js | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/lib/tls.js b/lib/tls.js index 409d7da5c5..a7908f77fc 100644 --- a/lib/tls.js +++ b/lib/tls.js @@ -645,15 +645,18 @@ Object.defineProperty(CryptoStream.prototype, 'readyState', { function CleartextStream(pair, options) { CryptoStream.call(this, pair, options); + // This is a fake kludge to support how the http impl sits + // on top of net Sockets var self = this; this._handle = { readStop: function() { self._reading = false; }, readStart: function() { - if (self._reading) return; + if (self._reading && self._readableState.length > 0) return; self._reading = true; self.read(0); + if (self._opposite.readable) self._opposite.read(0); } }; } |