response event don't prevent the program to output

[piranna]

The next code exists inmediatly without waiting to fully download the file:

got.stream.get(GCC_URL)
.on('response', function(res)
{
  res.pipe(fs.createWriteStream('out.tgz'))
})

Check it with some big file like GCC or linux kernel, it will only write just some kilobytes and exit in just a couple of seconds. On the other hand, the next "equivalent" code works flawlessly:

got.stream.get(GCC_URL).pipe(fs.createWriteStream('out.tgz'))

I think that if a response event is registered it should wait until the response stream is fully consumed.

[piranna]

I've found this also happens when using the request event.

[floatdrop]

This is because input and output streams, that returned from got is not piped anywhere and get stuck'd with filled buffer. In this situation node prefers to exit (even if there is stream, that can consume data).

[piranna]

This is because input and output streams, that returned from got is not
piped anywhere and get stuck'd with filled buffer. In this situation node
prefers to exit (even if there is stream, that can consume data).

The point is that app exit without error at all, and I'm using async.js and
callbacks are not being called too. Is that the expected behaviour?
Shouldn't exit with a "buffers filled" exception or something? Should I
open an issue on Node.js?

On the other hand, I think this is a valid use case, or is it intended to
use only the returned proxy and the 'request' and 'response' events are
mostly internal details? If so, I would deprecate them and use them
internally to fill the proxy object with the request and response methods.

I'm asking this because I'm doing a get request and need to wait to the
'request' event to get a reference to the request object so later I can be
able to call .abort() to interrupt it, so I think it would enought (and
simple) by adding a .abort() method and others alike to the proxy object.

[floatdrop]

I guess we can copy res properties and emit output stream here instead.

[szmarczak]

This can be fixed in a three ways:

1. enable flowing mode (recommended)

got.stream.get(GCC_URL)
.on('response', function(res)
{
  res.pipe(fs.createWriteStream('out.tgz'))
}).resume()

2. send the main stream to /dev/null (not recommended)

got.stream.get(GCC_URL)
.on('response', function(res)
{
  res.pipe(fs.createWriteStream('out.tgz'))
}).pipe(fs.createWriteStream('/dev/null'))

3. Increase output's highWaterMark. (needed only if you want to process it later)

Once the total size of the internal read buffer reaches the threshold specified by highWaterMark, the stream will temporarily stop reading data from the underlying resource until the data currently buffered can be consumed (that is, the stream will stop calling the internal readable._read() method that is used to fill the read buffer).

	const input = new PassThrough();
	const output = new PassThrough({highWaterMark: bytes});
	const proxy = duplexer3(input, output);