On 20/02/14 03:15, Jonathan Lu wrote:
Hi Michael,
Thanks a lot for your comments.
On Wed, Feb 19, 2014 at 6:28 PM, Michael McMahon
<michael.x.mcma...@oracle.com <mailto:michael.x.mcma...@oracle.com>>
wrote:
I think it's a good idea. Before changing anything though,
we would need to:
1. identify all APIs that could potentially be affected and
figure out what is
needed for each. For instance:
1. InetAddress
2. SocketPermission
3. URLPermission
4. HttpURLConnection
5. URL/URI
6. ...
Right, I assume all APIs which accept string-represented host names
would be affected.
It that may not be a big change from point of view.
1.
1. understand how it relates to URIs and IRIs. I haven't looked
into this much
but it seems that there might be potential for confusion given
that these entities
have their own encoding schemes already. I'm sure the issues
are all well thrashed out
already, but I'd like to see exactly how it will work in Java
before we start the work
For the potential confusion, were you meaning a confusion between URI
encoding (RFC-2396 [1]) and IDN ?
Right. As I said, it may just be a matter of checking RFC2396 (or its
successor RFC 3986).
I think RFC 3986 references IDNs.
Michael
Maybe, the work is within the scope of a small JEP, if nothing
else to define the scope
of the work.
Michael.
Copying core-libs-dev and security-dev to get more comments.
Many thanks
- Jonathan
[1] http://www.ietf.org/rfc/rfc2396.txt
On 19/02/14 04:00, Jonathan Lu wrote:
Hi net-dev,
If a Java application tries to support International Domain Names
(IDN) [1], which was firstly brought in Java6,
it has to write additional code or wrap java.net.IDN API [2] to
make the conversion each time it tries to resolve
a non-ASCII domain name, and use the converted punycode to make
connections to remote host, like:
java.net.IDN.toASCII("电 脑.info <http://xn--wnyy6w.info>");
It is easier for newly writen applications, since a wrappers can
be made in early design stage, but if
it comes to existing Java applications and third-party libraries,
IDN support would involve much more effort
like modifying the existing code base, inspecting libraries
interfaces/implementations, or even
re-implement some of the functions.
I'm wondering if it is possible to add IDN support into existing
Java APIs, like
java.net.InetAddress.getByName(), if JDK itself supports IDN, any
existing applications or libraries would
benefit from supporting IDN automatically without any source code
modifications.
Of course there's security risks regarding IDN homograph attacks
[1][2], so it may not be a
good idea to change the default behavior right now. But it would
still work if a simple switch can be
added into current JDK.
For example, by defining following the property in command like
options like
-Djava.net.AutoIDN=true
Any existing Java applications who wishes to support IDN feature
will be able to support IDN
without any changes to its source code or re-compilation.
What's your opinion on this ? any comment is welcome.
Thank you
- Jonathan Lu
-----------
[1] http://en.wikipedia.org/wiki/Internationalized_domain_name
[2] http://download.java.net/jdk8/docs/api/java/net/IDN.html
[3] http://www.unicode.org/reports/tr36/
[4] http://en.wikipedia.org/wiki/IDN_homograph_attack
