[ 
https://issues.apache.org/jira/browse/METRON-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15770711#comment-15770711
 ] 

ASF GitHub Bot commented on METRON-639:
---------------------------------------

Github user justinleet commented on the issue:

    https://github.com/apache/incubator-metron/pull/402
  
    I am concerned about the naming and documentation of the functions, given 
that URIs are used under the hood for everything. URIs are a super set of URLs, 
so now we have a set of URL specific functions that accept a superset of the 
documented and named input.
    
    e.g. URL_TO_PROTOCOL doesn't actually limit itself to URLs.  It happily 
accepts a (non-URL) URI, and returns an answer, even though by the name and 
documentation of the function I would really expect at least a warning, and 
more likely an error.  "urn:isbn:0451450523" isn't even a URL, but 
URL_TO_PROTOCOL informs me that its scheme is "urn".  This particular example 
obviously doesn't really apply to what we're doing, but one could imagine 
others do.
    
    Even if we choose to keep the naming as-is, I want to see tests on URIs 
that aren't URLs, to ensure that they behave rationally.


> The Network Stellar functions need to have better unit testing
> --------------------------------------------------------------
>
>                 Key: METRON-639
>                 URL: https://issues.apache.org/jira/browse/METRON-639
>             Project: Metron
>          Issue Type: Bug
>            Reporter: Casey Stella
>
> We have very little unit test coverage around the Networking functions in 
> Stellar at the edge level.  When diving a bit deeper on real data, I found a 
> number of bugs around:
> * Domains with TLDs that are not part of the proper set of TLDs
> * URIs with schemes that Java doesn't know about.
> * IN_SUBNET takes multiple CIDRs, but only evaluates the first one.
> Generally calling validate on these methods can be unsafe because they do not 
> handle null arguments correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to