http: do not replace .read() in IncomingMessage

Remove the req._consumed property, as its use is completely
superseded and not needed anymore. This was being set in the
overridden .read().

PR-URL: https://github.com/nodejs/node/pull/18939
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>

1 files changed, 0 insertions, 19 deletions

diff --git a/lib/_http_incoming.js b/lib/_http_incoming.js
index 696fcc3b4c..a84cb64bdb 100644
--- a/lib/_http_incoming.js
+++ b/lib/_http_incoming.js
@@ -38,13 +38,6 @@ function readStop(socket) {
 function IncomingMessage(socket) {
   Stream.Readable.call(this);
 
-  // Set this to `true` so that stream.Readable won't attempt to read more
-  // data on `IncomingMessage#push` (see `maybeReadMore` in
-  // `_stream_readable.js`). This is important for proper tracking of
-  // `IncomingMessage#_consuming` which is used to dump requests that users
-  // haven't attempted to read.
-  this._readableState.readingMore = true;
-
   this.socket = socket;
   this.connection = socket;
 
@@ -70,9 +63,6 @@ function IncomingMessage(socket) {
   this.statusMessage = null;
   this.client = socket;
 
-  // flag for backwards compatibility grossness.
-  this._consuming = false;
-
   // flag for when we decide that this message cannot possibly be
   // read by the user, so there's no point continuing to handle it.
   this._dumped = false;
@@ -88,15 +78,6 @@ IncomingMessage.prototype.setTimeout = function setTimeout(msecs, callback) {
 };
 
 
-IncomingMessage.prototype.read = function read(n) {
-  if (!this._consuming)
-    this._readableState.readingMore = false;
-  this._consuming = true;
-  this.read = Stream.Readable.prototype.read;
-  return this.read(n);
-};
-
-
 IncomingMessage.prototype._read = function _read(n) {
   // We actually do almost nothing here, because the parserOnBody
   // function fills up our internal buffer directly.  However, we