This repository has been archived by the owner. It is now read-only.

PhantonJS ignores proxy on 127.0.0.1 host #11342

Open
reed1 opened this Issue May 22, 2013 · 15 comments

Comments

Projects
None yet
@reed1

reed1 commented May 22, 2013

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

@bprosnitz

This comment has been minimized.

Show comment
Hide comment
@bprosnitz

bprosnitz Sep 20, 2013

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.

bprosnitz commented Sep 20, 2013

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.

@reed1

This comment has been minimized.

Show comment
Hide comment
@reed1

reed1 Sep 20, 2013

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

reed1 commented Sep 20, 2013

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

@ronwsmith

This comment has been minimized.

Show comment
Hide comment
@ronwsmith

ronwsmith Nov 18, 2013

+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.

ronwsmith commented Nov 18, 2013

+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.

@afn

This comment has been minimized.

Show comment
Hide comment
@afn

afn May 9, 2014

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 commented May 9, 2014

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.

@pboling

This comment has been minimized.

Show comment
Hide comment
@pboling

pboling May 9, 2014

@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.

pboling commented May 9, 2014

@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.

@mislav

This comment has been minimized.

Show comment
Hide comment
@mislav

mislav Dec 11, 2014

There's a PR for this #12703

Related issue: #12407

mislav commented Dec 11, 2014

There's a PR for this #12703

Related issue: #12407

@garytaylor

This comment has been minimized.

Show comment
Hide comment
@garytaylor

garytaylor Jan 7, 2015

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 :-(

garytaylor commented Jan 7, 2015

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 :-(

@rac2030

This comment has been minimized.

Show comment
Hide comment
@rac2030

rac2030 Mar 15, 2015

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).

rac2030 commented Mar 15, 2015

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).

@lkwg82

This comment has been minimized.

Show comment
Hide comment
@lkwg82

lkwg82 commented May 19, 2015

+1

@brownbl1

This comment has been minimized.

Show comment
Hide comment
@brownbl1

brownbl1 Sep 1, 2015

+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.

brownbl1 commented Sep 1, 2015

+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.

@abourget

This comment has been minimized.

Show comment
Hide comment
@abourget

abourget Sep 10, 2016

No progress on that ? I'm stuck in here with no support for no_proxy..

abourget commented Sep 10, 2016

No progress on that ? I'm stuck in here with no support for no_proxy..

@shankarkc

This comment has been minimized.

Show comment
Hide comment
@shankarkc

shankarkc Oct 14, 2016

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.

shankarkc commented Oct 14, 2016

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.

@ro31337

This comment has been minimized.

Show comment
Hide comment
@ro31337

ro31337 Nov 1, 2016

This one is very important for everyone

ro31337 commented Nov 1, 2016

This one is very important for everyone

@lkwg82

This comment has been minimized.

Show comment
Hide comment
@lkwg82

lkwg82 Nov 5, 2016

@ro31337 So, have you already offered a patch?

lkwg82 commented Nov 5, 2016

@ro31337 So, have you already offered a patch?

@rac2030

This comment has been minimized.

Show comment
Hide comment
@rac2030

rac2030 Nov 5, 2016

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.

rac2030 commented Nov 5, 2016

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.