Regarding 97b0b92 and trying to support IE8. I think the once module might be a problem there since it uses Object.defineProperty.

If it is, this could be an alternative: https://github.com/sindresorhus/onetime

https://github.com/isaacs/once/blob/master/once.js#L4
http://kangax.github.io/compat-table/es5/#Object.defineProperty

hi, i want to make a cors request and my code is like:

var req = httpify({
url: 'remoteurl address',
method: 'GET',
cors: true,
}, function (err, response, body) {
console.log(response);
});

but the request can not send with the cookies so i will get 401 response.

which part did i go wrong?

See relevant conversations at browserify/http-browserify#35 and browserify/http-browserify#47.

Solution

(headers["accept"] || headers["Accept"]) || (headers["Accept"] = "application/json") //Don't override existing accept header declared by user

Is this still readable?

Or should we loop over all headers and lowercase them (thus overwriting duplicates) ?

xhr.responseType === undefined in IE8

Currently you can abort requests like so:

var req = xhr(url, (err, resp) => {
   // ...
})

// when user cancels request
cancelButton.on('click', () => req.abort())

However, it just passes err as "Internal XMLHttpRequest Error" which makes it hard to distinguish between user-initiated cancellation and actual XHR errors.

If possible, it would be nice to emulate Node and use ECONNRESET for err.code when the error is due to an abort() rather than, say, a connection or JSON parse error. This way abstractions like xhr-request that work in Node/Browser could both use the same logic for handling req.abort().

Hi,

Related to my issue here: AmpersandJS/ampersand#47
Could you update [email protected] to the latest version (4.2.1)?

The version you are using (2.0.7) references [email protected], which references by mistake tape, which is only needed for tests purposes.
It increases quite a lot browserify's bundles for nothing.
Newer versions have corrected this.

Thanks!

It looks like all errors call the same error function but we need to know specifically when it's a timeout error to inform an adaptive video algorithm. Am I missing anything, or any suggestions on how it should be added?

Thanks.

[edited]

The idea is to find and configure a service for running tests in multiple browsers to monitor browser support automatically.

The trick is, we need the server side for the tests running in the same origin.

See how npm test does it now.

For GET (and possibly PUT & DELETE), options.json is not automatically added to the URL as parameter arguments. i.e.

xhr({url:'/service', json:{arg1:'foo', arg2:'bar'},function(err, resp, body){ })

/service?arg1=foo&arg2=bar

Most other libraries will do this so it would be great if this npm would also do this by defualt OR at least process as an options.

I was using xhr@latest from npm and just got hit by the InvalidStateError fixed in #8

Having these two lines outside of the main exporter function means, that the aliases are created before the module is required:

var XHR = window.XMLHttpRequest || noop
var XDR = "withCredentials" in (new XHR()) ?
        window.XMLHttpRequest : window.XDomainRequest

And since the aliases are already created, it is impossible to stub/mock XMLHttpRequest with e.g. http://sinonjs.org/docs/#server Considering that it is also impossible to fake out the exported function itself, it becomes practically impossible to properly unit test anything that uses the xhr module without having an actual HTTP server, which is not always feasible.

If the above two lines were inside createXHR() - we could hijack/fake XMLHttpRequest before calling the exported function. Aside from negligible performance impact, I don't really see any good reason not to do so - does one exist?

Would you accept a PR that made the project work on node by using node-XMLHttpRequest?

would you add node-XMLHttpRequest as a dependency if we marked it as 'false' in the browser field?

would make xhr nicely isomorphic w/o any overhead in the browser bundle

Came from conversation in #11, it would be nice to be able to configure the constructors of the XHR and XDR. From @Raynos:

require('xhr').set({
  XHR: function () { ... },
  XDR: function () { ... }
})

Currently we throw even if options.headers was an empty object. That's a bit harsh...

when sync == true xhr will crash with the following error:

InvalidAccessError: A parameter or an operation is not supported by the underlying object

On the line

xhr.withCredentials = !!options.withCredentials

On the related MDN page it is said that

Note: Starting with Gecko 11.0 (Firefox 11.0 / Thunderbird 11.0 / SeaMonkey 2.8), Gecko no
longer lets you use the withCredentials attribute when performing synchronous requests.
Attempting to do so throws an NS_ERROR_DOM_INVALID_ACCESS_ERR exception.

http://www.mocky.io/

Hey! Love this module — it's awesome. I'm wondering if you're open to one or both of the following convenience APIs in the same vein as request:

• xhr.post, xhr.put, etc. as shortcuts for their respective methods.
• Providing a string as the first parameter as the url for the request, with options as they are provided as the second parameter.

This would enable requests like this:

xhr.post("http://example.com", function (err, resp) {
  // ...
})

These would allow for more expressive xhr calls, though they'd introduce more than one way to do things and could slightly complicate this simple library with a magical API. IMHO this would be worth the tradeoff, but I thought I'd reach out before creating a PR or a wrapper library.

Thanks again.

in IE8 error handler can be called with no arguments. so evt variable can be undefined. Need to adapt to that.

request has some options that would be silently ignored if one tried to use them with xhr, eg.

requestORxhr({
  url: "http://google.com",
  qs: {
    q: "how do I search internet?"
  }
})

request will send the query, but xhr doesn't support qs (if it should is a totally different matter, we keep the size small)

Proposal:
run console.warn(optionKey+' option not implemented')

When opt.json is truthy, errors on JSON.parse() are swallowed.
https://github.com/Raynos/xhr/blob/bc9674d7d5f5c8870ab23fb736fbacc2b3f73518/index.js#L38-L40

Is there a recommended way of handling these errors while still supporting json: String option?

When we timeout a request in IE9, the onreadystatechange is called anyway and it errors
http://stackoverflow.com/questions/7287706/ie-9-javascript-error-c00c023f

I'm using Ampersand.js, which uses this module.

When running Browserify, I get the following error:

>> SyntaxError: Line 78: Unexpected token throw while parsing /var/www/onthego/client/node_modules/ampersand-model/node_modules/ampersand-sync/node_modules/xhr/index.js

Changing the options.headers... line back to a console warning fixes it (see this commit).

Not sure if this fix belongs here, but according to this jQuery ticket and personal experience, creating a new XHR object for each XHR request leaks memory in IE8-.

One option is to reuse a single XHR object, however this breaks in Safari, and Safari alone.

The other option is to use ActiveXObject, which is gross in and of itself.

I know, I know, it was just added :) But still - I'm raising this issue to at least get an official "no" - or maybe someone has a more concrete idea on how to decouple IE8 support / inject the header parsing function?

IE8 support depends on parse-headers, which is an extra 1.5kb browserified+minified. I'm using xhr itself exactly because it is small - ~2kb browserified+minified, so IE8 support effectively doubles the size. Some might say that's not much, but over here we have to save every byte (building a script for 3rd party sites...). Plus IE8 is not a Real Browser™ anyways.

I published a new version recently, but I couldn't publish 2.0.2 because it was already taken. There is no tag for 2.0.2. I can't find it, so I published 2.0.3 and all's well. But I feel like we should tag the 2.0.2 on the right commit or unpublish 2.0.2
I couldn't find the commit that was published as 2.0.2. That's the magic of DVCS ;)

Is there an easy helper to get access to the cookie information, or do we have to parse the header ourselves? If not, would you accept a patch that parsed the cookie information and accepted a key, returning the cookie's value?

I checked on virtual machines at work, and we lost support for old IEs
It seems that the only problem for now is that parse-headers is using .indexOf
Good news: noone reported that ;)

1. We need to re-run tests in IEs more often. Who can help? Who has experience with browserstack free for opensource option?
2. Change parse-headers or replace with something else?
3. Integration tests are not IE compatible, I'll fix them by the end of the week (my bad)

run-browser dependencies seem broken.

The latest testling run is dated 2014-07-22 and we had quite a lot of pushes since then.
Also, the browser support banner is invalid because of that.

What change to xhr caused the major version bump?

If options.json I think it makes sense to set headers: { Accept: 'application/json' }.

e.g

GET:

var options = {
  url: url,
  json: true,
  headers: { Accept: 'application/json' }
};
xhr(options, handle);

POST:

var options = {
  method: 'POST',
  url: url,
  json: true
};
xhr(options, handle);

Seems inconsistent to me

To be safe when handling various kinds of links, the xhr.send should be inside a try catch block

What do you think about this?
IE throw Invalid argument error in different cases: https://www.google.com/search?q=xhr%20ie%20invalid%20argument

This is the line generating the error:

xhr.status = xhr.statusCode = status

My code is super simple:

module.exports = function sendDataToServer(data, cb) {
  xhr({
    json: data,
    uri: "/url",
    method: "POST"
  }, function (err, resp, body) {
    cb(err, resp, body);
    // resp === xhr
    // check resp.body or resp.statusCode
  })
};

When a request is sent with a body and results in a http error response, the error message is created based on the response body, but the body is not passed to the error creating function and the request body is accidentally used.

seems introduced in 1.15

Is there any way to have GET request url parameters without appending them to the URL yourself beforehand?

Could not find any documentation on this.

By preferring XDomainRequest when available in IE8+, xhr precludes the use of setRequestHeader (and will never send the Cookie header).

Affects:

• IE8
• IE9
• IE10

When i add the header:

headers: {
                "Content-Type": "application/json"
}

The request changes to option instead of get

xhr object used to have request headers in headers when returned: https://github.com/Raynos/xhr/blob/v1.16.0/index.js#L37

A change in 1.16 rewrites that to become response headers:
https://github.com/Raynos/xhr/blob/v1.16.0/index.js#L165

I am not sure this was intended, but it might just be me.

Would you mind if I added semicolons to the code? I use xhr with browserify and minify it. There's the risk of some code being misinterpreted after newlines are removed when there's no semicolons.

As a user of XHR, I would expect it to realize when the request will require CORS and choose to use XDR. This is mostly an issue on browsers like IE8 and IE9 where a CORS request requires the usage of XDomainRequest.

var xhr = require('xhr');

module.exports = function (done) {
  var opts = {
    url: 'http://api.icndb.com/jokes/random', crossOrigin: true, json: null,
    //headers: Object.freeze({})
  };

  httpify(opts, cb);

  function cb (err, res, body) {
    console.log(err, body);
    done(err, JSON.parse(body).value.joke);
  }
}

module.exports(function(){});

Yields

OPTIONS http://api.icndb.com/jokes/random Request header field Content-Type is not allowed by Access-Control-Allow-Headers. bundle.js:102
XMLHttpRequest cannot load http://api.icndb.com/jokes/random. Request header field Content-Type is not allowed by Access-Control-Allow-Headers. quote.html:1
Error {statusCode: 0} null

Uncommenting the headers: Object.freeze({}) line fixes the issue. This is obviously an awful hack, maybe we shouldn't touch Content-Type when CORS

xhr is a good replacement for request module in node, the options object is compatible and the callback function signature as well. The only important difference is that request passes the error variable not null only when an actual error happens in it. If http call ends in non-2xx response, error is still null.

It would break the backwawrd-compatibility, but we could consider switching to matching logic, so that xhr can be used two-platform projects as a straightforward replacement of the request module.

thoughts?

The request library has a helpful form option, which is the equivalent of doing:

request({
    form: body
})
// is equivalent to...
request({
    body: querystring.stringify(body).toString('utf8'),
    headers: {"Content-Type": "application/x-www-form-urlencoded"}
})

The option handles the body stringification & header-setting for me, which I find much easier to work with. Is there any interest to add a similar option to xhr? It would make moving from request to nets much easier for myself and a lot of others.

Happy to submit a PR if so.

beforeSend is browser specific, not from request API, so we could consider making it follow the spec of the beforeSend from jQuery.ajax.

Thoughts?

Currently if I set options.cors to true to get XDR to be used in IE I have to use beforeSend to turn allowCredentials back off. It should be a separate setting IMHO.

Setting options.cors has no effect on non-IE8/9 browsers except it can cause the error:

XMLHttpRequest cannot load https://qqqq A wildcard '*' cannot be used in the 
'Access-Control-Allow-Origin' header when the credentials flag is true. 
Origin 'https://aaaa' is therefore not allowed access.

Any reason that you're using uri instead of url.

I can submit a pull request to alias one to the other. Makes it easier to use as a drop in replacement in Browserify.

IE6,7 have serious memory leaks if you don't register unload handlers to do cleanup.
https://github.com/LearnBoost/engine.io-client/blob/master/lib/transports/polling-xhr.js#L289

Is it possible to send FormData as the body? The docs claim "anything that's valid as a parameter to xhr.send should work", but my requests seem to fail (a server error about boundary not being defined). I defined the Content-Type headers as multipart/form-data, but this doesn't do the trick.