vterron / public-ip

A Python function to get your public IP address
MIT License
13 stars 6 forks source link

There is a link in the 'URLs' that no longer responding. #5

Open h-bin-kim opened 3 months ago

h-bin-kim commented 3 months ago

https://api.ipify.org/

The site https://api.ipify.org/ has been discontinued, slowing down the main function of this repository. Just wanted to let you know.

vterron commented 3 months ago

Thanks for reaching out!

That's weird — https://api.ipify.org/ does work for me:

❯ curl https://api.ipify.org/ 
XXX.YYY.200.43
h-bin-kim commented 3 months ago

I still can't reach it, so I don't know if there are any access restrictions due to country or specific conditions.

> curl https://api.ipify.org/ 
curl: (6) Could not resolve host: api.ipify.org

Glad most users have no issues.

vterron commented 3 months ago

Interesting. Are you by any chance located in any of these countries?

2024-07-15-164630_663x595_scrot

They were failing last evening on https://www.whatsmydns.net/#A/api.ipify.org (error "DNS query timed out").

h-bin-kim commented 3 months ago

Thank you for checking. I am in South Korea. It is one of the countries where DNS lookups for api.ipify.org are not working. I'm glad to know the cause!

vterron commented 3 months ago

Thanks for confirming!

This is an interesting corner case — one of the backends not being reachable by a subset of users, for... whatever reason.

We could add some functionality to work around this (e.g. by adding a knob to exclude some of the servers), but would it be worth it? The default timeout is one second, and it can be modified when calling the get() function. Is this enough for you, or would you need to be able to exclude that server?

h-bin-kim commented 3 months ago

First, there is an item to add for exception handling:

requests.exceptions.ConnectionError

The error I encountered was ConnectionError. By handling this exception, we can prevent unnecessary Traceback output.


However, exception handling will not improve response latency in my case. Since this is an issue where no connection is established, setting a timeout doesn't help solve the problem.

0.024s elapsed for https://icanhazip.com
0.223s elapsed for https://checkip.amazonaws.com
0.241s elapsed for https://ipinfo.io/ip
0.282s elapsed for https://ipecho.net/plain
0.563s elapsed for https://ifconfig.co/ip
20.021s elapsed for https://api.ipify.org
h-bin-kim commented 3 months ago

The simplest solution I found is to replace the URL https://api.ipify.org with https://api64.ipify.org. Fortunately, it appears that 'https://api64.ipify.org' is accessible from all countries.

'https://www.whatsmydns.net/#A/api64.ipify.org' (After a few attempts, it works fine in all countries.)

image

I considered various other solutions, but none were better than this I think.


Below are some of the alternative solutions I considered. This ties into a problem-solving pattern I often think about, and I don't dislike how such simple solutions(above) emerge after contemplation. :)

  1. Forcibly terminating the _get_ip thread based on timeout:

    • Since the time elapses in the requests.get() method's subroutine, it's not possible to forcibly terminate it properly from the thread.
    • While switching to the multiprocessing.Process method could achieve the desired outcome, I wanted to avoid using multiprocessing for this lightweight tool, so I kept this as a last resort.
  2. Simply removing https://api.ipify.org from the list:

    • Although not critical, I didn't want to solve the problem in such an irresponsible manner.
  3. Filtering URLs based on connectivity:

    • In my implementation, the connectivity check also took about 20 seconds regardless of the timeout setting. (for api.ipify.org)
    • Checking connectivity too quickly might be inaccurate.
  4. Checking the country setting in the OS and excluding api.ipify.org from the list only if it is KR:

    • No comments. :joy: