maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Schultze (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MSHARED-609) Partially revert MSHARED-429
Date Sun, 08 Jan 2017 07:52:58 GMT

    [ 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:52 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 not 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). 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.

> 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)

Mime
View raw message