substack/hyperquest — pull request #17 by twolfson (2013-04-29 06:35:03+00:00)
Title: Added in alternative protocol support

This is a patch which applies to browsers exclusively. I am currently developing a browser extension and attempting to use browserify in the process.

The problem:
When an HTTP request is made, the protocol was being reset to `chrome://` (`window.location.protocol` in a browser extension). After a bit of sniffing, I discovered it was being caused by no protocol being passed to `http-browserify` which falls back to `window.location.protocol`.

```js
// The following was making a call to `chrome://google.com/`
hyperquest.get({
uri: 'http://google.com/'
}, function (err, res) {
console.log(res);
});
```

The problem is the default no longer applies in this strange edge case. Instead, the `protocol` returned by `url.parse` should be passed on as the `scheme` to `http-browserify`.

As a result, I have made it become an explicit passing. As an aside, `XMLHttpRequest` can hit any protocol (e.g. `ftp`, `chrome`, `https`). Here is a page I played with to make sure I was sane.

ftp://ftp.graphicsmagick.org/pub/GraphicsMagick/1.3/

```js
// You will need to be on the page for cross-domain reasons
x = XMLHttpRequest();
x.open('GET', 'ftp://ftp.graphicsmagick.org/pub/GraphicsMagick/1.3/');

x.onreadystatechange = function () {
console.log(x.responseText);
};

x.send()
```