Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python Selenium Client is by default resolving ip adresses and not sending domain names #1729

Closed
aluedeke opened this issue Mar 2, 2016 · 7 comments · Fixed by #7430
Closed
Labels

Comments

@aluedeke
Copy link

aluedeke commented Mar 2, 2016

Expected Behavior -

If the configured endpoint is app.testobject.com the HTTP request should got to app.testobject.com and not the ip address behind app.testobject.com

Actual Behavior -

when setting the selenium endpoint to a domain the outgoing http request is going to the ip adress. That confuses WebServers which are proxying commands to the selenium backend, as they usually use domain names and not ip addresses to find the right config.

Steps to reproduce -

Initiate a session to an non local endpoint (e.g. one of the cloud testing providers like sauce and browserstack). Record the http requests using Charles Proxy (or Wireshark). The request is send to an ip instead to the domain.

The problem can be found here:

https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/remote/remote_connection.py#L165

I would recommend to change the default behaviour to false.

@jleyba jleyba added the C-py label Mar 4, 2016
@isaulv
Copy link
Contributor

isaulv commented Mar 17, 2016

It seems this commit added the resolve_ip flag:
d4af5ec
to support the Edge driver.

@aluedeke
Copy link
Author

i am actually fine with resolving the ip (why ever this is needed, don't know any software doing something like that), i just believe the default should be not resolving the ip, like e.g. any web browser in the world does it.

@mehmetg
Copy link

mehmetg commented Jul 22, 2016

This is causing #2509. Is there a reason why one would want to resolve the ip first?

Disabling that solves #2509.

kvdveer added a commit to ondergetekende/selenium that referenced this issue Feb 15, 2017
Resolving the IP never necessary, httplib does that for us. Worse,
it is always the wrong thing to do when dealing with HTTPS
connections, as no certificates are issued for IP-adresses. IMHO
there is no reason to keep this feature around.

While I was at it, I also added HTTPS support for keepalive
connections; which always defaulted to HTTP, even if a HTTPS url
was provided.

Fixes SeleniumHQ#1729
Fixes SeleniumHQ#2509
Fixes SeleniumHQ#3514
@ghost
Copy link

ghost commented Mar 29, 2017

+1

@windmgc
Copy link

windmgc commented May 17, 2017

+1 for this, the default behavior of resolving urls into ips will be confusing and hard to debug when you are using some techniques like lvs & nginx reverse proxy.

@albdv
Copy link

albdv commented May 22, 2017

+1

GQAssurance added a commit to GQAssurance/selenium that referenced this issue Jul 25, 2019
Resolving the IP within Selenium is never necessary; This is always the wrong thing to do when dealing with HTTPS connections, as no certificates are issued for IP-addresses.

This is a conflict-free update of PR SeleniumHQ#3515.

Fixes SeleniumHQ#1729
Fixes SeleniumHQ#2509
AutomatedTester pushed a commit that referenced this issue Jul 27, 2019
Resolving the IP within Selenium is never necessary; This is always the wrong thing to do when dealing with HTTPS connections, as no certificates are issued for IP-addresses.

This is a conflict-free update of PR #3515.

Fixes #1729
Fixes #2509
loly89 pushed a commit to loly89/selenium that referenced this issue Aug 1, 2019
Resolving the IP within Selenium is never necessary; This is always the wrong thing to do when dealing with HTTPS connections, as no certificates are issued for IP-addresses.

This is a conflict-free update of PR SeleniumHQ#3515.

Fixes SeleniumHQ#1729
Fixes SeleniumHQ#2509
@lock
Copy link

lock bot commented Aug 26, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Aug 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
6 participants