[
https://issues.apache.org/jira/browse/MSHARED-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15808948#comment-15808948
]
Jan Schultze edited comment on MSHARED-609 at 1/8/17 7:47 AM:
--------------------------------------------------------------
Agreed. The port range should be extended.
And yes, my patch did fix the wrong end. However, that was a conscious decision
based on the following reasoning. I wanted to change as little as possible in
order to avoid creating problems for other people. I did and do not know who
consumes {{UrlValidator}}. Given the recent explosion of TLDs it seemed (and
that is only my personal impression) odd to validate TLDs, especially with a
hard coded set of more than 1000 names. Also, the deprecated "non-routines"
{{UrlValidator}} originally used in Maven tried to "validate" TLDs by
restricting them to a maximum of 4 characters. That's what actually prevented
{{.local}} from being used in Maven sites. Concerning domain validation in
general I felt that depending on the use case a DNS lookup validating the fully
qualified name or a purely syntactical analysis should be employed. So I
decided that I do not understand the component and cannot fix it because I do
not know if it is really broken or working as intended. However, given its
behavior it was used in the wrong way in Maven. So I decided to fix the wrong
end.
Do you know if there is a good reason for this kind of "static" TLD validation
in {{DomainValidator}}?
Your suggested solution would change the behavior of {{isValid(String)}} or
need a new flag to allow link-local (in addition to the
{{UrlValidator.ALLOW_MDNS_HOSTNAME}} flag). What would you prefer?
Concerning Maven - I personally think that URL validation for project URLs is
not necessary at all. If it is, it should be validated upon build time with a
meaningful warning for the producer not the consumer.
was (Author: jan.schultze):
Agreed. The port range should be extended.
And yes, my patch did fix the wrong end. However, that was a conscious decision
based on the following reasoning. I wanted to change as little as possible in
order to avoid creating problems for other people. I did and do not know who
consumes {{UrlValidator}}. Given the recent explosion of TLDs it seemed (and
that is only my personal impression) odd to validate TLDs, especially with a
hard coded set of more than 1000 names. Also, the deprecated "non-routines"
{{UrlValidator}} originally used in Maven tried to "validate" TLDs by
restricting them to a maximum of 4 characters. That's what actually prevented
{{.local}} from being used in Maven sites. Concerning domain validation in
general I felt that depending on the use case a DNS lookup validating the fully
qualified name or a purely syntactical analysis should be employed. So I
decided that I do not understand the component and cannot fix it because I do
not know if it is really broken or working as intended. However, given its
behavior it was used in the wrong way in Maven. So I decided to fix the wrong
end.
Do you know if there is a good reason for this kind of "static" TLD validation
in {{DomainValidator}}?
Your suggested solution would change the behavior of {{isValid(String)}} or
need a new flag to allow link-local (in addition to the
{{UrlValidator.ALLOW_MDNS_HOSTNAME}} flag).
Concerning Maven - I personally think that URL validation for project URLs is
not necessary at all. If it is, it should be validated upon build time with a
meaningful warning for the producer not the consumer.
> Partially revert MSHARED-429
> ----------------------------
>
> Key: MSHARED-609
> URL: https://issues.apache.org/jira/browse/MSHARED-609
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-reporting-impl
> Affects Versions: maven-reporting-impl 2.4
> Reporter: Michael Osipov
> Assignee: Michael Osipov
> Fix For: maven-reporting-impl 3.0
>
>
> MSHARED-429 introduced handling of hostnames endling with {{.local}} though
> they are invalid in the way they are used.
> Copied from the ticket:
> I'd seriously like to revert this partially for 3.0:
> * Your DNS setup is simply broken. {{.local}} is a reserved TLD for mDNS
> resolution. This is not meant to be used in private networks. Doing so breaks
> Avahi on Linux/FreeBSD, Bonjour on macOS and everything else using zeroconf.
> You should register a domain name and use subdomains on your private network
> (https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS).
> * It does not accept full 16-bit unsigned integer
> * You always have to update with the newest pattern in Commons Validator
> Local hostnames (unqualified) can be validated by passing an option/flag to
> the validator. The rest of the patch, missing TLDs, etc. are already in
> Commons Validator 1.5.1.
> We should not encourage bad setups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
