[
https://issues.apache.org/jira/browse/MSHARED-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822917#comment-15822917
]
Michael Osipov edited comment on MSHARED-609 at 1/14/17 7:52 PM:
-----------------------------------------------------------------
bq. Do you know if there is a good reason for this kind of "static" TLD
validation in {{DomainValidator}}?
I think yes, because any type of TLD is validated with an
{{isValid...Tld(String)}} method.
bq. Your suggested solution would change the behavior of {{isValid(String)}}
and need a new flag to allow link-local (in addition to the
{{UrlValidator.ALLOW_MDNS_HOSTNAME}} flag). What would you prefer?
This should not be a default option, but a boolean flag to the
{{#getInstance()}} method with {{boolean allowLinkLocal}}. {{#isValid()}} would
work accordingly with the internal flag. Since {{UrlValidator}} uses
{{DomainValidator}}, it think it should require {{ALLOW_LINK_LOCAL_URLS}}
becaues mDNS is the technology behind and not the hostname style.
Apple provides [good
documentation|https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/NetServices/Articles/domainnames.html#//apple_ref/doc/uid/TP40002460-CJBDIAHA]
about it as well as the [RFC 6762, Section
3|https://tools.ietf.org/html/rfc6762#section-3].
bq. 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.
I fully agree here. I am inclined to remove it altogether because people could
use SFTP, SSH, S3, FTPS, SMB and all of them are valid, but considered invalid
by us -- which is wrong. There is no bulletproof way for us to tell wether a
URL is correct or not. We could pass it at most to {{URI}} and see the result.
Moreover, a {{href}} does not necessarily has to be a URL at all. I will create
a new ticket for removing the validation as a whole.
was (Author: michael-o):
bq. Do you know if there is a good reason for this kind of "static" TLD
validation in {{DomainValidator}}?
I think yes, because any type of TLD is validated with an
{{isValid...Tld(String)}} method.
bq. Your suggested solution would change the behavior of {{isValid(String)}}
and need a new flag to allow link-local (in addition to the
{{UrlValidator.ALLOW_MDNS_HOSTNAME}} flag). What would you prefer?
This should not be a default option, but a boolean flag to the
{{#getInstance()}} method with {{boolean allowLinkLocal}}. {{#isValid()}} would
work accordingly with the internal flag. Since {{UrlValidator}} uses
{{DomainValidator}}, it think it should require {{ALLOW_LINK_LOCAL_URLS}}
becaues mDNS is the technology behind and not the hostname style.
Apple provides [good
documentation|https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/NetServices/Articles/domainnames.html#//apple_ref/doc/uid/TP40002460-CJBDIAHA]
about it as well as the [RFC 6762, Section
3|https://tools.ietf.org/html/rfc6762#section-3].
bq. 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.
I fully agree here. I am inclined to remove it altogether because people could
use SFTP, SSH, S3, FTPS, SMB and all of them are valid, but considered invalid
by us -- which is wrong. There is no bulletproof way for us to tell wether a
URL is correct or not. We could pass it at most to {{URI}} and see the result.
I will create a new ticket for removing the validation as a whole.
> 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)
