Localhost no longer recognized
23pointsNorth opened this issue · 5 comments
Setup:
python3 -m pip install --upgrade validators==0.22.0
Code to reproduce:
import validators
validators.url("http://127.0.0.1:80/")
validators.url("http://localhost:80/")
Expected outcome:
Both calls to return true.
Similar to the other issue, this commit c43826c seems to comment the tests for localhost
Hi @23pointsNorth, please refer #285 (comment)
Right, thanks for pointing it out. I remember the documentation noted that it was introduced as of 0.11.x as a new feature.
A problem with the suggested solution is that simple_host=True also allows for
>>> validators.url("http://l:8000/", simple_host=True)
True
which is not a valid "default" hostname. So in essence, we still need to regex localhost in the target URL?
It is true, that l or 13 are not common hostnames, but they are valid though.
In a (W)LAN, I could have my hosts named as a, b, c, ... or even 1, 2, 3, ... etc. It's not a clever naming scheme (and not recommended) but definitely legal. So a GET http://13:8080 from host c to host 13 is quite valid indeed.
Currently URL validation accepts all of these parameters:
def url(
value: str,
/,
*,
skip_ipv6_addr: bool = False,
skip_ipv4_addr: bool = False,
may_have_port: bool = True,
simple_host: bool = False,
strict_query: bool = True,
rfc_1034: bool = False,
rfc_2782: bool = False,
):It is possible to add another boolean parameter say only_localhost, but I think it might not be good for the following reasons:
simple_hostmust beTrueforonly_localhostto work. - complexity- should
only_localhostrefer to literallocalhoststring or all hostnames defined in/etc/hosts? - confusion - AFAIK, hostnames such as
abc,xyz, etc. are very uncommon. - viability
Instead, if an user want to ensure that an URL is strictly localhost, one could:
from validators import url as is_valid_url
from urllib.parse import urlsplit
if is_valid_url(given_url, simple_host=False) and urlsplit(given_url).netloc == 'localhost' :
# do somethingThanks, I understand the perspective, just assumed some stability of the API.
Happy for you to close the issues as resolved.
Thanks for using validators. Feel free to ping this thread if any ideas pop up.