Skip to content
This repository has been archived by the owner on Mar 3, 2020. It is now read-only.

Proxy is in use when request goes to 127.0.0.1 #883

Closed
avsh opened this issue Mar 2, 2016 · 7 comments
Closed

Proxy is in use when request goes to 127.0.0.1 #883

avsh opened this issue Mar 2, 2016 · 7 comments

Comments

@avsh
Copy link

avsh commented Mar 2, 2016

Hello!

We faced with the problem.

We do tests using capybara and capybara-webkit. Our setup states to use a proxy server to go to wlan.

Also we run TestApp on 127.0.0.1 where features go to chat with our app.

But when we setup a proxy for Webkit driver, it uses proxy for 127.0.0.1 as well and features failed because proxy server doesn't have running app on its 127.0.0.1 interface.

However QT docs http://doc.qt.io/qt-5/qnetworkaccessmanager.html#setProxy say that no proxy in use if url is 127.0.0.1 or ::1 (if IPv6)

Please verify that and advise how to fix the issue in our tests.

@jferris
Copy link
Member

jferris commented Mar 2, 2016

However QT docs say that no proxy in use if url is 127.0.0.1 or ::1 (if IPv6)

I don't see where in the docs it says that. I see this in the docs for setProxy:

A proxy set with this function will be used for all requests issued by QNetworkAccessManager.

This makes it sound like the behavior you're seeing is expected.

I do see this in the docs, though:

For example, a proxy factory could apply the following rules: if the target address is in the local network (for example, if the hostname contains no dots or if it's an IP address in the organization's range), return QNetworkProxy::NoProxy

This makes it sound like we could bypass the proxy for certain requests, but that doesn't seem to be how it works by default.

Basically, if we wanted to make it possible to bypass the proxy for specific hosts, I think that would be possible using a QNetworkProxyFactory. If you're interested in submitting a pull request to make this configurable, I'd be open to it.

I'm going to close this issue, as it doesn't seem like a bug in capybara-webkit, but feel free to continue commenting and asking questions.

@jferris jferris closed this as completed Mar 2, 2016
@avsh
Copy link
Author

avsh commented Mar 2, 2016

Hello!

Thank you for your prompt reply.

setProxy accepts QNetworkProxy and the class description http://doc.qt.io/qt-5/qnetworkproxy.html states

Network proxy is not used if the address used in connectToHost(), bind() or listen() is equivalent to QHostAddress::LocalHost or QHostAddress::LocalHostIPv6.

@ghost
Copy link

ghost commented Mar 3, 2016

Mmmh.. Please don't implement it like this. This would break my setup. I support capybara-webkit in a project to test proxies. In the test suite for that project I need to run a proxy and a webserver listening on localhost/127.0.0.1

[ Test Suite ] -> [ Proxy 127.0.0.1:8080 ] -> [ Web Server 127.0.0.1:8080]

Besides that, I think it doesn't make sense to add an exception for 127.0.0.1 and the like. Better use a so called "proxy.pac" for this.

@jferris
Copy link
Member

jferris commented Mar 3, 2016

@avsh

setProxy accepts QNetworkProxy and the class description http://doc.qt.io/qt-5/qnetworkproxy.html states ...

Interesting. That's definitely not what we're seeing. Maybe that only applies to an application-wide proxy? We build our own QNetworkAccessManager for the QWebPage instances.

@dg-ratiodata

Mmmh.. Please don't implement it like this.

If we implemented proxy exceptions, it would be as a configurable list, similar to remote request whitelisting.

@avsh
Copy link
Author

avsh commented Mar 4, 2016

@jferris I will try to implement the SetIgnoreProxy option to accept list of hosts to exclude to be accessed via proxy.

@ghost
Copy link

ghost commented Mar 7, 2016

If we implemented proxy exceptions, it would be as a configurable list, similar to remote request whitelisting.

Thanks a lot.

@EugenioLaghi
Copy link

Any updates on this? I need to emulate the behavior of no_proxy too.

If anybody worked/is working on this feature I'm available to help completing it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants