AsynchronousDefinition would allow to load the lib asynchronously in the browser:

    require('http', function(http) {
        // do stuff with http here
    });

http://requirejs.org/ and other asynchronous loaders support this.

In the library, this consists of wrapping all the code in a function that will be called by the loader when appropriate (after all dependencies are loaded, etc):

    define(['dependency1', 'dependency2', ...], function(dep1, dep2, ...) {
        var http;
        http.request = ...;

        return http;
    });

Response data in http-browserify seems to default to text. In node http it seems to default to buffer. Independent of defaults, the node version supports setEncoding so you can change the type of the response. The browserify version should do the same.

http-browserify assumes a normal browser window and not a worker, though http requests in a worker are legitimate

inside a webworker the global object is self not window

You can do:

var bundle = browserify({
    require : { http : 'http-browserify' }
});

in order to map "http-browserify" over require('http') in your browserified source.

I am confused. Should not things just work after browserify my.js -o bundle.js? Where and when do I use this?

After using http to make a request to GitHub's /users/$username/repos API to list repo names, I was able to get my code working in the server, but it's failing on the browser.

[Error] XMLHttpRequest cannot load https://api.github.com/users/bucaran/repos. 
Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.

When I make this request

{
  host: "http://www.reddit.com/r/jokes/.json?limit=100?",
  path: "/",
  method: "GET",
  withCredentials: false // this is the important part
}

I get this error:

 XMLHttpRequest cannot load file://http://www.reddit.com/r/jokes/.json?limit=100/. Cross origin requests are only supported for protocol schemes: http, data, chrome-extension, https, chrome-extension-resource.

I have no idea why it's prepending "file://" to "http://", and it's totally fucking up my day...

Is there any cure for this?

If not specified, http-browserify sets the protocol to window.location.protocol. This differs from the behavior of Node (see https://nodejs.org/api/http.html#http_http_request_options_callback ). I assume the reasoning was to make https requests if the current location is also https (but I could be wrong here).

Does it make sense to mimic Node's behavior exactly, and just default to http: ?

The issue I'm running into is when running a script locally in the browser, so the protocol is "file:". http-browserify then tries to make file:// requests, which obviously fail.

This took me a little while to track down today -- I browserified an api client that was setting content-length when POSTing. This resulted in the posts hitting the server, but complete silence in the browser client code. It turns out this line was my problem (request.js line 23):

            if (!self.isSafeRequestHeader(key)) return;

Now, of course, my server doesn't actually care if content-length isn't sent, so I just stopped setting that header. I'm mostly apathetic about browserified code sending it versus node code (now) not sending it, since it works either way. But...

Is there a better way to do this?

More importantly -- is this the right way to handle "unsafe" headers? With no error, warning, etc. it makes it difficult to debug.

Server is a digest auth node.

HTTPDigest.prototype.request = function (data, options, callback) {
    var self = this;
    http.request(options, function (res) {
      self._handleResponse(data, options, res, callback);
    }).end();
  };

if I do this in node I receive a 401 with nonce in order than to make the second request (the real one)
when browserified the a popup for the credentials is poped and the the function is not called but only after you click ok or cancel button.

Hi,
I am using browserify, and I am facing an issue with some modules (example node-couchdb) that require the http module.
The error is Cannot set property 'maxSockets' of undefined
After some debugging, it seems that globalAgent is not defined in the http-browserify module.
Do you have any hints regarding this issue? Do you think this can fixed on your side?
Thank you

Hello.

Just ran into this issue and it had be really stumped for a while. Since the program I am working on runs both in the browser and in node, and the response bodies with JSON were the same, I could not for the life of me figure out why I got "unexpected end of input" when the URLs, responses and everything were the same. The reason was that if a string response holds the exact phrase "ArrayBuffer" that particular buffer will be converted into a Uint8Array (ref https://github.com/substack/http-browserify/blob/c0869e5f1d57eac1ce12305e226eadf82b052e07/lib/response.js#L107)

For a POC, I have put together this page: https://eiriksm.github.io/browserify-test (read the console and watch the network tab for what it was supposed to look like).

Now, I didn't come here just to complain, so I tried to make a solution to this in a PR coming in 2 seconds. I am not 100% sure how this is supposed to be used, but at least it worked when I was sending buffers from a http.createServer. But as I said, I am not 100% sure how it is supposed to work, so corrections are of course welcome. The actual line of code is based on the style that follows in the next function in the file the patch alters (isArray)

The Base64 package no longer exists on NPMJS: https://www.npmjs.com/package/Base64

The package.json dependency needs to be switched to 'base64' (lowercase) and reference version 2.1.0.

Like sending cookies automatically and accepting gzip.
Couldn't find that info in the documents.

https://github.com/substack/http-browserify/blob/master/lib/response.js#L107

Due to the way this regex is used, a response String that contains the substring "ArrayBuffer" is assumed to be an ArrayBuffer. For example, http-browserify cannot load a page containing its own source because the regex will select itself.

Since nodejs/node@235036e, node has been updated to return HTTP status codes to match the IANA ones.

Please update your code so they match.
e.g: 302 Moved Temporarily is now 302 Found.

Is it possible to upgrade the dependency Base64 from the current ~0.2.0 to latest (1.1.0)?

I have verified that Base64 is really only used once in http-browserify code and changing versions wouldn't break anything even though the semver indicates otherwise.

The root cause of my problems is that Base64 v0.2.0 offers WTFPL which is not white listed in our org. So static code analysis tools flag it as a policy violation. Base64 v 1.1.0 , on the other hand allows Apache 2.0 which is white listed in our org.

If there is a way to install the latest version of Base64 and make http-browserify point to this latest version then that could work as well. Note that webpack aliasing won't work since we need to pass static code analysis scrutiny which probably works off package-lock.json

Hi,

I use node-fetch in a reacts + rails project. I use https://github.com/shakacode/react_on_rails to glue between reactjs and Rails. Everything works fine except when I do server side rendering it complains the error "Encountered error "Error: no window object present" when prerendering".

I am willing to work a PR, just need some directions. Thanks!

The line that raise the error:

https://github.com/substack/http-browserify/blob/master/index.js#L54

I've been testing streaming JSON parsing and i ran in to this bug.

https://gist.github.com/mikeal/5471142

If you comment out the json parsing lines (those fail earlier than this bug surfaces due to a jsonstream bug, you can watch the length of all the chunks that get emitted.

In Firefox these events eventually stop and if you kill the server you'll get an exception when trying to read the last of the data.

In Chrome you'll eventually stop getting chunks with any data in them and it'll emit thousands of zero length chunks.

On node.js, the HTTP response object (which is named IncomingMessage in node.js) inherits from Stream.Readable:

util.inherits(IncomingMessage, Stream.Readable);

but in http-browserify, it only inherits from Stream:

util.inherits(Response, Stream);

This means the full stream API is not available as it is in Node, including the .resume() method. I believe this is the reason for this hack in the request module:

  } else if (response.resume) {
    // response.resume should be defined, but check anyway before calling.
    // Workaround for browserify.
    response.resume()
  }

to improve compatibility would it be possible for http-browserify Response to inherit from Stream.Readable? (are there any other changes needed than changing the utils.inherits call?)

edit: Stream is old-style (pre-0.10); this amounts to converting http-browserify to Streams2

Doesn't seem to work on mobile

var url = { 
    host: "localhost:8081",
    hostname: "localhost",
    href: "http://localhost:8081/api/foo?bar=baz",
    method: "GET",
    path: "/api/foo?bar=baz",
    pathname: "/api/foo",
    port: "8081",
    protocol: "http:",
    query: "bar=baz",
    search: "?bar=baz",
    slashes: true
  };
  var request = http.get(url, noop);

expected: "http://localhost:8081/api/foo?bar=baz"
actual:   "http://localhost:8081:8081/api/foo?bar=baz"

The url that is requested has the port in it 2 times. This is because of this line.
https://github.com/substack/http-browserify/blob/master/index.js#L7

I am finishing up a pull request to fix this where it will try host first, then hostname+port.

Please let me know if you have any input.

I understand HTTP header names are case-insensitive (RFC 2616). I'm currently interacting with an API that does not follow protocol, it works via node's https but not browserify's.

If you want complete compatibility with node, I'd say remove the case insensitivity. Otherwise, if you want to just follow the spec, I understand.

In the meantime, I've been able to get my API working, by modifying the browserify source code to remove the tolowercase for the headers

The buffer implementation is a lot of code and http-browserify does not really need it to work. It is only needed for auth parameter to bas64 encode it.

Could it be document that the auth parameter is not supported or changed to depend on a base64 library or? Eg. base64-js which buffer-browserify depends on.

In Node.js, when using the request function of the http module, you can subscribe to the error events of the returned object, such as:

var http = require('http');

var req = http.request('aaa.bbb.ccc.ddd', function (res) {
  console.log(res.statusCode);
});

req.on('error', function (err) {
  console.log('###');
});

req.end();

When I run this with a non-existent IP on Node.js, everything is fine, and the result is ### printed to the console.

When I run this using http-browserify in Chrome, I get an uncaught exception. Am I doing something wrong?

If window.location.href is http://localhost:8000/app/#/, one would expect a GET to ./ping to be a request to http://localhost:8000/app/ping. At least, that's how XMLHttpRequest behaves.

But instead it looks like http.request sends the request to http://localhost:8000./ping, which is not a valid URL...

http://nodejs.org/api/http.html#http_request_abort

I ran across this when using request's timeout option that uses abort() internally.

Currently the local xhrHttp is defined at require-time.

Unfortunately, libraries for mocking out XMLHttpRequests that rely on replacing global.XMLHttpRequest with a mock do not play nicely with this - you've already gained a reference to the real XMLHttpRequest by the time they replace the global.XMLHttpRequest reference.

Will be submitting a pull request to fix.

[email protected] supports using a string as the request parameter. If it is one, it converts it into an object via url.parse.

http.request.get('http://github.com/');

// equivalent to
http.request.get({
  hostname: 'github.com'
});

https://github.com/joyent/node/blob/85e4fc4306055656f0acab0052ae6da73bfbeb1f/lib/http.js#L53-L55

I was wondering if the lack of support for this in http-browserify was intentional or not (it left me scratching my head for a bit until I saw the cause). If it was unintentional, I would be more than happy to make a PR for this.

First time I'm using Browserify, first test, and I stumble on that... ;)

It currently doesn't seem to support setTimeout.

When I dial this into the latest browserify:

var bundle = browserify({
    require : { http : 'http-browserify' }
});

I get an error saying Error: path must be a string.

Please update with correct configuration instructions!

See: http://stackoverflow.com/questions/30869460/node-js-browserify-error-on-parsing-tar-file/30878794#30878794, browserify/stream-browserify#8

It would be nice if this module emitted actual instances of Buffer so that it is compatible with other streams, specifically for .pipe

Request is missing setNoDelay method that exists on the node.js version.
Some libs (e.g. EventSource) call this method.

The response object in Node's http module (an instance of http.IncomingMessage) exposes the response headers via response.headers (and not response.getHeader()). This module does the opposite - http-browserify's response object has response.getHeader() (and not response.headers).

The response object should be changed to match Node core's http module by adding .headers and removing .getHeader().

When doing a HEAD request with the http library, the javascript just crashes and does not give me any answers.

I tried debugging it myself and found that the library uses fetch to fetch the head. The response of this message is given to IncomingMessage. IncomingMessage assumes that a response has a body. In the case of Edge, the body is just null, because a HEAD request has no body.

Nonetheless, this is accessed in anyway:

var reader = response.body.getReader()
		function read () {
			reader.read().then(function (result) {
				if (self._destroyed)
					return
				if (result.done) {
					self.push(null)
					return
				}
				self.push(new Buffer(result.value))
				read()
			}).catch(function(err) {
				self.emit('error', err)
			})
		}

And libraries crashes, causing the HEAD request to hang indefinitely.

To be able to use my own code I added a monkey fix, to temporarily make edge work:

window.fetch_old = window.fetch
window.fetch = function () {
    var result = window.fetch_old.apply(null, arguments);
    result.then_old = result.then;
    result.then = function (callback) {
        return result.then_old(function(response) {
            if(response.body === null){
                var body = { "getReader" : function () {
                 return {
                     "read" : function (){
                         return {
                             "then" : function (callback){
                                 callback({"done":true});
                                 return {"catch" : function(){}};
                             }
                         }
                     }
                 }   
                }};
                //override body....
                var handler = {
                    get: function(target, name) {
                        if(name === "body"){
                            return body;
                        }
                        return target[name];
                    }
                };
                var response_new = new Proxy(response, handler);
                return callback(response_new);
            }
            return callback(response);
        });
    }
    return result;
};

But obviously, it would be great if this could be fixed in the library, instead of my ugly hack.

http-browserify accepts a 'responseType' parameter to set the XHR response type. However, in Firefox 31 at least, the logic to set the response type always fails because it is set before xhr.open() is called.

The call to set 'xhr.responseType = params.responseType' fails with 'An attempt was made to use an object that is not, or is no longer, usable' ala. http://stackoverflow.com/questions/13216903/get-binary-data-with-xmlhttprequest-in-a-firefox-extension

base64-js is used in the buffer module, so it would save a little bit of duplication.

Is there a good reason to have two implementations?

XHR2 added

req.send(FormData);
req.send(Blob);
req.send(ArrayBuffer);

Posting FormData can be done using something like:

  var fd = new FormData()
  fd.append('image', file)
  var req = new XMLHttpRequest()
  req.onload = function () {
    callback(null, req.responseText)
  }
  req.onerror = callback
  req.open('post', 'https://api.imgur.com:443/3/image.json')
  req.setRequestHeader('Authorization', 'Client-ID ' + clientID)
  req.send(fd)

However, I can see know way of handling FormData using the built in http module.

(see browserify/browserify#439)

@substack doesn't appear to have time to maintain this; perhaps you could put out a call for a maintainer? There are a large number of open PRs and issues, but no commits for a long time.

I know I can upgrade.
But I recommend at least updating minor version.

Because now for example browserify requires 0.8 too.

"http-browserify" : "~0.1.1",

c5ffd1d#L2R13