PhantonJS ignores proxy on 127.0.0.1 host
reed1 opened this issue · comments
Try to open a page, example
var page = require('webpage').create();
page.open('http://localhost:8080', function () {
page.render('shot.png');
phantom.exit();
});
with pahntomjs --proxy cmd options, then it won't pass through the proxy. I have proxy and webserver both on local
Thanks
I want to bring attention to this issue again. Is there any way to connect to localhost via a proxy with Phantom JS?
The option to allow this exists in Chrome, but I don't see a way to do it with Phantom JS.
Yes there is, use other than 'localhost', example if u're using windows place like
user-laptop 127.0.0.1
to system32/drivers/etc/hosts, and use that domain on phantomjs to fetch something like 'http://user-laptop/bla..', it will work. But still it's not pretty
+1. I need this feature in the case of having several local rack apps communicating during development, but in CI we need to use proxying as only one app runs at a time there.
Note that it can often be useful to skip the proxy for connections to localhost, so the best fix for this would be not to change the default behavior, but rather to introduce a new option, e.g. "--proxy-localhost", which uses the proxy server for all connections including 127.0.0.1.
@afn I second that. Please do not change default behavior here. This is (apparently) the only thing that allows us to have a modicum of stability in our feature tests.
I vote for a change here - perhaps a --no-proxy option which defaults to 'localhost,127.0.0.1' or something like - this way, it will not break anyone's test suite etc... Those wishing to use something like puffing-billy or agile-proxy can then set no-proxy to ''. At the minute, I am having to find the test runner machine's ip address and make the request via that as both localhost and 127.0.0.1 do not go via the proxy :-(
using the actual IP of the localhost works that the proxy gets triggered.
I though first that this issue is related to what I experienced but it seems my issue was just that I need to set the proxy trough cli args from ghostdriver as the selenium way does not work with special ssl proxy, defining it as http proxy trough cli fixed it (while adding the overhead of the proxy instead of direct connection, SSL proxy is used only to inject client certificates).
+1
+1. to clarify what @rac2030 said above about using the IP since I was confused at first: Setting the application host to use either my local ip or my hostname is the workaround that worked for me. At first I tried setting my proxy host to my ip/hostname but that didn't do anything. Might not be confusing for all, but my use-case has the proxy and application on the same machine.
No progress on that ? I'm stuck in here with no support for no_proxy..
Can you please bring this to closure. Its an important feature. All enterprise use proxy. To reach our test environment we need to skip proxy.
This one is very important for everyone
@ro31337 So, have you already offered a patch?
Given there is an easy workaround, I don't see it as an urgent feature (and it's not a bug as this is the default behaviour and if then it would need to be changed in QT itself like done in PR #12703 which has never been merged.
Note that changing 3d party library code in a project itself introduces a maintenance overhead whenever you want to update the library to a newer version.
QT Documentation states it clearly:
Network proxy is not used if the address used in connectToHost(), bind() or listen() is equivalent to QHostAddress::LocalHost or QHostAddress::LocalHostIPv6.
Another option instead of the changes on the QT core libs like odne in the pending pull request could be just adding an option like --localhost-proxy which would just intercept the navigate method and first evaluates the local IP and replaces localhost or 127.0.0.1 with it. More thoughts on implementation would be on the cases where the machine has no network connection at all or multiple IP's.
Due to our very limited maintenance capacity, we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed (see #15395 for more details). In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!