From 008ab12b7facea8ac4a718894044963e3b4ee901 Mon Sep 17 00:00:00 2001
From: isaacs <i@izs.me>
Date: Wed, 20 Mar 2013 16:14:36 -0700
Subject: [PATCH] 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.
---
 lib/tls.js | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

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);
     }
   };
 }