Replace http-browserify with stream-http

[jhiesey]

stream-http uses new-style streams to provide true streaming or
pseudo-streaming in as many browsers as possible.

It uses the new fetch api with native browser streams where available
(currently only chrome supports this combination) and various
browser-specific xhr extensions to make binary-safe streaming
work where possible.

It is tested and working with at least basic functionality
back to IE8.

[jhiesey]

I am certainly willing to test it with some important modules that require('http') in browserify if anyone can suggest some good test cases.

[jhiesey]

cc @feross

[ghost]

This looks good from a once-over of the stream-http source.

It seems to work with the request module, but the 'end' event is firing twice somehow, possibly a request bug:

var request = require('request');

var r = request(location.protocol + '//' + location.host + '/x.txt');
var chunks = 0;
r.on('data', function () { chunks ++ });
r.on('end', function () { console.log('chunks=', chunks) });

$ browserify -r stream-http:http x.js > bundle.js

I also get this warning in chrome 41:

Refused to set unsafe header "host"

[jhiesey]

It looks like the double 'end' is coming from this (arguably wrong and no longer necessary) logic in request: https://github.com/request/request/blob/master/request.js#L931

However, I also don't think stream-http should be emitting 'close', since there is no real underlying socket and node (at least often?) doesn't emit it even if the connection definitely does close.

These should be fixed in v1.1.1

[jhiesey]

By the way, on the subject of warnings, I'd love to eliminate these in chrome:

The provided value 'ms-stream' is not a valid enum value of interface XMLHttpRequestResponseType.
The provided value 'moz-chunked-arraybuffer' is not a valid enum value of interface XMLHttpRequestResponseType.

I don't have any idea how to do this, however, while still doing the feature detection I'm trying to do.

[feross]

@jhiesey The issue with the unhidable warning should probably be opened up as a bug on chromium: https://code.google.com/p/chromium/issues/list

[feross]

@jhiesey If node emits 'close', which the docs say it does, then I think browserify should do the same. Users could be listening for that event. (It's weird that you're seeing node sometimes not emit the 'close' event.)

Also, I think the bug with request could be fixed by making sure that 'end' is emitted before 'close' is since they set self._ended = true on 'end' here: https://github.com/request/request/blob/master/request.js#L940

[feross]

I would also implement request.destroy even though it's not documented, because people probably depend on it.

[jhiesey]

OK, I think I've addressed all of these issues.

[feross]

If there are no other objections, I think this is ready to merge.

To be safe, I think this should be a major version bump. We did the same when we switched the buffer implementation in v3.

Let's wait a few days to give other people a chance to weigh in on this PR?