You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are these intended behaviour? I haven't dug too hard into the referenced RFCs so it's possible they are valid, but ISTR there was previously a 'cannot start with a number' rule that was subsequently relaxed to allow some, but not exclusively, leading digits.
Following examples I think probably all(?) should actually be False?
In [38]: !pip freeze | grep fqdn
fqdn==1.5.1
In [39]: fqdn.FQDN('1').is_valid
Out[39]: False
In [40]: fqdn.FQDN('1', min_labels=1).is_valid
Out[40]: True
In [41]: fqdn.FQDN('127.0.0.1').is_valid
Out[41]: True
In [42]: fqdn.FQDN('127.thing.0.1').is_valid
Out[42]: True
In [43]: fqdn.FQDN('127.0.0.0.1').is_valid
Out[43]: True
I could convert those into tests in a PR if it does seem like a bug?
For my use it would ideally either accept a valid IP address (without a trailing FQ dot), or a valid hostname, but not something like 1.2.3.4.5, although separating valid IPs from invalid 'dotted numeric' inputs is something I can handle if it doesn't make sense here.
A quick poke around some of the docs, found in RFC1123, sec 2.1:
If a dotted-decimal number can be entered without such
identifying delimiters, then a full syntactic check must be
made, because a segment of a host domain name is now allowed
to begin with a digit and could legally be entirely numeric
(see Section 6.1.2.4). However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
The text was updated successfully, but these errors were encountered:
Are these intended behaviour? I haven't dug too hard into the referenced RFCs so it's possible they are valid, but ISTR there was previously a 'cannot start with a number' rule that was subsequently relaxed to allow some, but not exclusively, leading digits.
Following examples I think probably all(?) should actually be False?
I could convert those into tests in a PR if it does seem like a bug?
For my use it would ideally either accept a valid IP address (without a trailing FQ dot), or a valid hostname, but not something like
1.2.3.4.5
, although separating valid IPs from invalid 'dotted numeric' inputs is something I can handle if it doesn't make sense here.A quick poke around some of the docs, found in RFC1123, sec 2.1:
The text was updated successfully, but these errors were encountered: