[jira] [Commented] (VALIDATOR-421) InetAddressValidator IPV4 rejects IPs with leading 0's in octets
[
https://issues.apache.org/jira/browse/VALIDATOR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15959019#comment-15959019
]
Matt Kusnierz commented on VALIDATOR-421:
-
ok, maybe not strictly a bug; but ambiguous != invalid. Are there any systems
that reject an IPv4 address with leading 0's? If not, although some systems
might interpret the leading 0's differently that doesn't make an IP address
with leading 0's invalid... I'm not saying it is a good idea; and it isn't
ambiguous; but it is not strictly invalid. This class also broken behavioural
backwards compatibility, because this leading 0's check was not there in
earlier versions (e.g. 1.4.0) causing an upgrade to generate late
run-time/validation errors that could easily slip through testing and only get
reproduced in production.
I would suggest an enhancement that exposes an overloaded
isValidInet4Address(string inet4Address, Ipv4Strictness strictness) method
enum Ipv4Strictness {
DECIMAL_STRICT, //enforced leading zeros
DECIMAL_RELAXED, //allows leading zeros
HEX,
OCTAL
}
I would suggest that the default should in fact get reverted to the relaxed
strictness mode; especially if oracle java 8 accepts IPs in this format.
> InetAddressValidator IPV4 rejects IPs with leading 0's in octets
>
>
> Key: VALIDATOR-421
> URL: https://issues.apache.org/jira/browse/VALIDATOR-421
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
>Affects Versions: 1.6
>Reporter: Matt Kusnierz
>
> According to Wikipedia "It [IPv4] also allowed the numbers to be written in
> hexadecimal and octal, by prefixing them with 0x and 0, respectively", but
> org.apache.commons.validator.routines.InetAddressValidator.isValidInet4Address(String)
> rejects IPs if an ipSegment starts with a leading 0.
> So leading 0's should be detected first, and then used to try and parseInt
> using the octal radix.
> The ipv4 regex also doesn't support hex notation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (VALIDATOR-421) InetAddressValidator IPV4 rejects IPs with leading 0's in octets
[ https://issues.apache.org/jira/browse/VALIDATOR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Kusnierz updated VALIDATOR-421: Description: According to Wikipedia "It [IPv4] also allowed the numbers to be written in hexadecimal and octal, by prefixing them with 0x and 0, respectively", but org.apache.commons.validator.routines.InetAddressValidator.isValidInet4Address(String) rejects IPs if an ipSegment starts with a leading 0. So leading 0's should be detected first, and then used to try and parseInt using the octal radix. The ipv4 regex also doesn't support hex notation. was: According to Wikipedia "It [IPv4] also allowed the numbers to be written in hexadecimal and octal, by prefixing them with 0x and 0, respectively", but org.apache.commons.validator.routines.InetAddressValidator.isValidInet4Address(String) rejects IPs if an ipSegment starts with a leading 0. So leading 0's should be detected first, and then used to try and partInt using the octal radix. The ipv4 regex also doesn't support hex notation. > InetAddressValidator IPV4 rejects IPs with leading 0's in octets > > > Key: VALIDATOR-421 > URL: https://issues.apache.org/jira/browse/VALIDATOR-421 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.6 >Reporter: Matt Kusnierz > > According to Wikipedia "It [IPv4] also allowed the numbers to be written in > hexadecimal and octal, by prefixing them with 0x and 0, respectively", but > org.apache.commons.validator.routines.InetAddressValidator.isValidInet4Address(String) > rejects IPs if an ipSegment starts with a leading 0. > So leading 0's should be detected first, and then used to try and parseInt > using the octal radix. > The ipv4 regex also doesn't support hex notation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (VALIDATOR-421) InetAddressValidator IPV4 rejects IPs with leading 0's in octets
[ https://issues.apache.org/jira/browse/VALIDATOR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957126#comment-15957126 ] Matt Kusnierz commented on VALIDATOR-421: - https://en.wikipedia.org/wiki/Dot-decimal_notation > InetAddressValidator IPV4 rejects IPs with leading 0's in octets > > > Key: VALIDATOR-421 > URL: https://issues.apache.org/jira/browse/VALIDATOR-421 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.6 >Reporter: Matt Kusnierz > > According to Wikipedia "It [IPv4] also allowed the numbers to be written in > hexadecimal and octal, by prefixing them with 0x and 0, respectively", but > org.apache.commons.validator.routines.InetAddressValidator.isValidInet4Address(String) > rejects IPs if an ipSegment starts with a leading 0. > So leading 0's should be detected first, and then used to try and partInt > using the octal radix. > The ipv4 regex also doesn't support hex notation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (VALIDATOR-421) InetAddressValidator IPV4 rejects IPs with leading 0's in octets
Matt Kusnierz created VALIDATOR-421: --- Summary: InetAddressValidator IPV4 rejects IPs with leading 0's in octets Key: VALIDATOR-421 URL: https://issues.apache.org/jira/browse/VALIDATOR-421 Project: Commons Validator Issue Type: Bug Components: Routines Affects Versions: 1.6 Reporter: Matt Kusnierz According to Wikipedia "It [IPv4] also allowed the numbers to be written in hexadecimal and octal, by prefixing them with 0x and 0, respectively", but org.apache.commons.validator.routines.InetAddressValidator.isValidInet4Address(String) rejects IPs if an ipSegment starts with a leading 0. So leading 0's should be detected first, and then used to try and partInt using the octal radix. The ipv4 regex also doesn't support hex notation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-319) ArchiveStreamFactory.createArchiveInputStream(InputStream) Does not support tar.gz files
[
https://issues.apache.org/jira/browse/COMPRESS-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679130#comment-14679130
]
Matt Kusnierz commented on COMPRESS-319:
I would have thought that the ArchiveStreamFactory should still have
detected either the tar or the gz signature though allowing you to use it
to do the two stage unpacking yourself. But it does not. That to me feels
like a bug. Doing the two step unpacking all in one go does sound like an
enhancement. But since tar.gz is so common I was surprised it wasn't there
already.
> ArchiveStreamFactory.createArchiveInputStream(InputStream) Does not support
> tar.gz files
>
>
> Key: COMPRESS-319
> URL: https://issues.apache.org/jira/browse/COMPRESS-319
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.9
>Reporter: Matt Kusnierz
>
> Trying to extract from a tar.gz file, the
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveInputStream(InputStream)
> throws an ArchiveException("No Archiver found for the stream signature")
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COMPRESS-319) ArchiveStreamFactory.createArchiveInputStream(InputStream) Does not support tar.gz files
Matt Kusnierz created COMPRESS-319:
--
Summary:
ArchiveStreamFactory.createArchiveInputStream(InputStream) Does not support
tar.gz files
Key: COMPRESS-319
URL: https://issues.apache.org/jira/browse/COMPRESS-319
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.9
Reporter: Matt Kusnierz
Trying to extract from a tar.gz file, the
org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveInputStream(InputStream)
throws an ArchiveException("No Archiver found for the stream signature")
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-480) IOUtils.closeQuietly can throw NullPointerException
[ https://issues.apache.org/jira/browse/IO-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578580#comment-14578580 ] Matt Kusnierz commented on IO-480: -- If the intended use of this method is to perform a best efforts attempt to close the inputStream and not to worry about exceptions; doesn't it make sense to simply catch Exceptions instead of just IOExceptions. I agree that in this case the NullPointerException should not be thrown in the first place; so the core java FilterInputStream; and/or the JarURLConnectopm$JarUrlInputStream sub-class is at fault; but there could be any number of other poor inputStream implementations out there; and closing them quietly is still the goal of this utility method. Otherwise the user may be forced to re-wrap the call to closeQuietly with another try-catch; which makes closeQuietly redundant. > IOUtils.closeQuietly can throw NullPointerException > --- > > Key: IO-480 > URL: https://issues.apache.org/jira/browse/IO-480 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.4 >Reporter: Matt Kusnierz > Original Estimate: 10m > Remaining Estimate: 10m > > The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions > will be ignored. This is not the case, as the code only catches IOExceptions. > As this example stack trace shows, it is possible for some InputStreams to > throw NullPointerExceptions during close: > java.lang.NullPointerException: null > at java.io.FilterInputStream.close(FilterInputStream.java:155) > ~[na:1.6.0_35] > at > sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) > ~[na:1.6.0_35] > at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) > ~[commons-io-2.1.jar:2.1] > at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) > ~[commons-io-2.1.jar:2.1] > Close quietly should do as advertised/suggested and catch all Exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-480) IOUtils.closeQuietly can throw NullPointerException
[ https://issues.apache.org/jira/browse/IO-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14577000#comment-14577000 ] Matt Kusnierz commented on IO-480: -- I have tried to raise this with Oracle through my support companies support contract; and they appear to be reluctant to fix this in the FilterInputStream. The closeQuietly method says that it should silently swallow ANY / all exceptions; so I still think that it makes sense to fix this within IOUtils. > IOUtils.closeQuietly can throw NullPointerException > --- > > Key: IO-480 > URL: https://issues.apache.org/jira/browse/IO-480 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.4 >Reporter: Matt Kusnierz > Original Estimate: 10m > Remaining Estimate: 10m > > The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions > will be ignored. This is not the case, as the code only catches IOExceptions. > As this example stack trace shows, it is possible for some InputStreams to > throw NullPointerExceptions during close: > java.lang.NullPointerException: null > at java.io.FilterInputStream.close(FilterInputStream.java:155) > ~[na:1.6.0_35] > at > sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) > ~[na:1.6.0_35] > at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) > ~[commons-io-2.1.jar:2.1] > at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) > ~[commons-io-2.1.jar:2.1] > Close quietly should do as advertised/suggested and catch all Exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-480) IOUtils.closeQuietly can throw NullPointerException
[ https://issues.apache.org/jira/browse/IO-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567280#comment-14567280 ] Matt Kusnierz commented on IO-480: -- Also tried with v2.4 java.lang.NullPointerException: null at java.io.FilterInputStream.close(FilterInputStream.java:155) ~[na:1.6.0_35] at sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) ~[na:1.6.0_35] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:303) ~[commons-io-2.4.jar:2.4] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:246) ~[commons-io-2.4.jar:2.4] > IOUtils.closeQuietly can throw NullPointerException > --- > > Key: IO-480 > URL: https://issues.apache.org/jira/browse/IO-480 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.4 >Reporter: Matt Kusnierz > Original Estimate: 10m > Remaining Estimate: 10m > > The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions > will be ignored. This is not the case, as the code only catches IOExceptions. > As this example stack trace shows, it is possible for some InputStreams to > throw NullPointerExceptions during close: > java.lang.NullPointerException: null > at java.io.FilterInputStream.close(FilterInputStream.java:155) > ~[na:1.6.0_35] > at > sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) > ~[na:1.6.0_35] > at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) > ~[commons-io-2.1.jar:2.1] > at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) > ~[commons-io-2.1.jar:2.1] > Close quietly should do as advertised/suggested and catch all Exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-480) IOUtils.closeQuietly can throw NullPointerException
[ https://issues.apache.org/jira/browse/IO-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Kusnierz updated IO-480: - Description: The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions will be ignored. This is not the case, as the code only catches IOExceptions. As this example stack trace shows, it is possible for some InputStreams to throw NullPointerExceptions during close: java.lang.NullPointerException: null at java.io.FilterInputStream.close(FilterInputStream.java:155) ~[na:1.6.0_35] at sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) ~[na:1.6.0_35] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) ~[commons-io-2.1.jar:2.1] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) ~[commons-io-2.1.jar:2.1] Close quietly should do as advertised/suggested and catch all Exceptions. was: The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions will be ignored. This is not the case, as the code only catches IOExceptions. As this example stack trace shows, it is possible for some InputStreams to through NullPointerExceptions during close: java.lang.NullPointerException: null at java.io.FilterInputStream.close(FilterInputStream.java:155) ~[na:1.6.0_35] at sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) ~[na:1.6.0_35] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) ~[commons-io-2.1.jar:2.1] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) ~[commons-io-2.1.jar:2.1] Close quietly should do as advertised/suggested and catch all Exceptions. > IOUtils.closeQuietly can throw NullPointerException > --- > > Key: IO-480 > URL: https://issues.apache.org/jira/browse/IO-480 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.4 >Reporter: Matt Kusnierz > Original Estimate: 10m > Remaining Estimate: 10m > > The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions > will be ignored. This is not the case, as the code only catches IOExceptions. > As this example stack trace shows, it is possible for some InputStreams to > throw NullPointerExceptions during close: > java.lang.NullPointerException: null > at java.io.FilterInputStream.close(FilterInputStream.java:155) > ~[na:1.6.0_35] > at > sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) > ~[na:1.6.0_35] > at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) > ~[commons-io-2.1.jar:2.1] > at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) > ~[commons-io-2.1.jar:2.1] > Close quietly should do as advertised/suggested and catch all Exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IO-480) IOUtils.closeQuietly can throw NullPointerException
Matt Kusnierz created IO-480: Summary: IOUtils.closeQuietly can throw NullPointerException Key: IO-480 URL: https://issues.apache.org/jira/browse/IO-480 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.4 Reporter: Matt Kusnierz The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions will be ignored. This is not the case, as the code only catches IOExceptions. As this example stack trace shows, it is possible for some InputStreams to through NullPointerExceptions during close: java.lang.NullPointerException: null at java.io.FilterInputStream.close(FilterInputStream.java:155) ~[na:1.6.0_35] at sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) ~[na:1.6.0_35] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) ~[commons-io-2.1.jar:2.1] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) ~[commons-io-2.1.jar:2.1] Close quietly should do as advertised/suggested and catch all Exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
