Last modified: 2014-08-29 01:56:26 UTC
Since parsoid doesn't seem to take the environment variable http_proxy into account the following fails: $ env | grep prox http_proxy=http://proxy:80/ $ npm test ... { [DoesNotExistError: Page Fetch failure for "http://en.wikipedia.org/w/api.php": Error: connect ECONNREFUSED] name: 'DoesNotExistError', message: 'Page Fetch failure for "http://en.wikipedia.org/w/api.php": Error: connect ECONNREFUSED', code: 404 }
A little more searching, I discover this isn't really parsoid's fault, but node.js's http library doesn't really support proxies like more mature programming environments. http://geekswithblogs.net/shaunxu/archive/2013/09/05/semi-global-proxy-setting-for-node.js.aspx /me sighs
"more mature programming environments". ha! You mean the not-even-in-POSIX-and-certainly-not-in-libc "http_proxy" convention, I guess, used by senile software. ;) We use the `request` module (https://github.com/mikeal/request) which has an `proxy` argument to the constructor. This can be configured in your localsettings.js; see the api/localsettings.js.example file in Parsoid. You can put parsoidConfig.defaultAPIProxyURI = process.env['http_proxy']; in your localsettings.js if it makes you feel better.
(In reply to C. Scott Ananian from comment #2) > You mean the not-even-in-POSIX-and-certainly-not-in-libc "http_proxy" > convention, I guess, used by senile software. ;) I admit to being over 40, but I don't think I'm quite qualified to be called senile. I prefer the title "seasoned" for my dormant sysadmin skills. Skills which, truth be known, find it very useful to set http_proxy once in /etc/environment and then have it used by all software on that host. > We use the `request` module (https://github.com/mikeal/request) which has an > `proxy` argument to the constructor. Getting the request module to respect http_proxy is certainly an upstream problem. That wasn't my goal in filing this this bug. > You can put > > parsoidConfig.defaultAPIProxyURI = process.env['http_proxy']; > > in your localsettings.js if it makes you feel better. This statement is dismissive of the de facto http_proxy standard. Why?
I've learned the hard way that http_proxy isn't really a standard at all. Hardly anything respects it, and modern software uses the system proxy settings (set via gnome, kde, etc) instead of relying on a standard-which-isn't. Let's not even touch the question of whether http_proxy should be used for https traffic. Anyway, there's a perfectly straightforward workaround, which I've provided. [The 'senile software' was intended to be a lighthearted joke. I apologize if it appeared otherwise.]
