InetAddress API extension

[Sergey Chernyshev]

Hi David,
Thank you for your comments.

Am 28.03.24 um 21:09 schrieb David Lloyd:
>
>     I would like to propose a PR to extend the InetAddress API in JDK
>     23, namely to provide interface to constructing InetAddress
>     objects from literal addresses in POSIX/BSD form (please see the
>     discussion [1]), to the Apps that need to mimic the behavior of
>     POSIX network APIs (|inet_addr|) used by standard network
>     utilities such as netcat/curl/wget and the majority of web
>     browsers. At present time, there's no way to construct
>     |InetAddress| object from such literal addresses because the new
>     API |InetAddress.ofLiteral()| and |Inet4Address.ofLiteral()| will
>     consume an octal address and successfully parse it as decimal,
>     ignoring the octal prefix. Hence, the resulting object will point
>     to a different IP address than it is expected to point to. There's
>     also no direct way to create an InetAddress from a literal address
>     with hexadecimal segments, although this can be the case in
>     certain systems.
>
> Would this proposal be unique to IPv4 addresses, or is there an 
> equivalent for IPv6? (I would suspect that there isn't, given that the 
> parsing rules for IPv6 are a bit more well-defined...)

Yes this is IPv4 specific.

>     It is suggested to add a new factory method such as
>     |.ofPosixLiteral()| to |Inet4Address| class to fill this gap. This
>     won't introduce ambiguity into the API and won't break the long
>     standing behavior. As a new method, it will not affect Java
>     utilities such as HttpClient, nor the existing Java applications.
>     At the same time, the new method will help dealing with confusion
>     between BSD and Java standards.
>
>
> I would suggest normatively calling this behavior "POSIX standard" 
> parsing (not BSD or POSIX/BSD), since it (at least nominally) comes 
> from a standards body [1]. Bear in mind that `inet_pton` follows 
> different rules though [2]. RFC 6943 [3] has a bit more to say about 
> so called "loose" vs "strict" IP address parsing rules.

Thanks, I will put a note on it in the PR and update the motivation text 
accordingly.

>     There could be a slight discrepancy in terms of how different
>     standard tools are working under different OS. For example in
>     MacOS wget & nc disregard octal prefix (0) while allowing
>     hexadecimal prefix (0x), at the same time curl & ping process both
>     prefixes. In Ubuntu Server 22.04 both prefixes are processed, but
>     they are not allowed in /etc/hosts file, while in MacOS it's legal
>     to use 0x. Despite the deviations in how and where the BSD
>     standard is implemented, there are two distinct approaches. I
>     don't see why Java should't provide two different indepentent
>     APIs. It would give the future apps flexibility to decide which
>     standard to rely on, ability to see the full picture.
>
>     Please share your thoughts on whether such a change might be
>     desirable in JDK 23. Thank you for your help!
>
> I guess it could be useful when the need arises to interoperate with 
> tooling that supports this kind of syntax, and if it was done, I would 
> agree that a separate method would be the way to go. But, I don't have 
> any comment as to whether the potential use cases are sufficient to 
> justify the API surface and additional implementation complexity 
> (whatever that may be).

This is the primary use case of the proposed API. Implementaions that 
rely on inet_addr() syntax are still too widespread to ignore them.

>
> As another random data point: the projects I've been working on have 
> relegated such extra-JDK IP address handling tasks to a utility 
> library [4]. We don't have a parser for this particular syntax though.

I think Guava and Apache Commons both have similar utility classes. 
Neither of them have that syntax. But I also see libraries that do have 
that syntax - an example is IPAddress library 
(https://github.com/seancfoley/IPAddress).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240329/7f8b2995/attachment-0001.htm>