xmlhttprequest dependency

[mardiros]

I don't find documentation why you don't use a regular package for xmlhttprequest

https://github.com/Automattic/engine.io-client/blob/master/package.json#L28

I have also open an issue at npm about this problem

npm/npm#7832

[metamatt]

This also seems to prevent installation with jspm:

% jspm install socket-io.client
... snip ...
err  Repo github:rase-/node-XMLHttpRequest@add/ssl-support not found!

warn Installation changes not saved.

[frostme]

has anyone started working on this? or at least an explanation? I can't see anywhere on why this is a dependency to a github repo instead of a regular package. Currently is breaking my team from upgrading to sails 11 from sails 10, because we're using private network with our own npm.

[metamatt]

Heh, #348 is really the same issue.

And also #358, which (alone of all these issues) actually has a discussion of why use a fork.

[metamatt]

Also, while we're talking about this (xmlhttprequest in EIO): socketio/socket.io-client#679 is an old SIO issue (well that incarnation is only a year old but I remember people complaining about it long before that: socketio/socket.io-client#344, https://gist.github.com/jfromaniello/4087861) about how in the browser you can use cookies to authenticate socket.io pretty easily, but it doesn't work when using using socket.io-client in NodeJS (either as a real socket.io client of other services, or for tests of your own socket.io service) because there's no real user agent, and no cookies. And you can't just add cookie headers because xmlhttprequest won't let you because it's against the XHR spec because XHRs were designed to be used on top of a real user agent. People end up patching xmlhttprequest to allow cookies, just for this scenario.

To my way of thinking, EIO shouldn't use XHR in NodeJS anyway. It should use XHR in the browser, and could use some other request library (https://github.com/request/request or https://github.com/visionmedia/superagent?) over pure HTTP in NodeJS, giving more control over the requests since you don't have to depend on/fight with the user agent. In this scenario, it wouldn't depend on xmlhttprequest at all. I don't know how big a code change this is...

[RonaldTreur]

3 of the current 13 open issues seem to relate to the xmlhttprequest-issue. This currently breaks every dependency downstream (hundreds!) for organizations that are unable to access Github (due to proxy/firewall).

This issue was originally reported over half a year ago, but has not yet been addressed. I'd like to add my +1 to see this issue resolved in the near future. I guess simply publishing the fork @rase- created would work for the short term. A (slightly) longer-term solution like @metamatt proposes would be best of course.