给JDK提交了一个bug, 然而...

这其实是去年就踩的一个坑了, 之前又踩到一个类似的, 于是想起在这里来分享一下. 背景是这样的:

我们的项目依赖于一个外部服务, 该外部服务提供 REST 接口供我方调用, 本地测试和测试环境都没有问题, 但是一上生产环境就发现网络不通. (本地测试/测试环境, 生产环境网络通过不通的域名访问该外部服务), 且在生产环境通过 curl 等命令能够正常调用对方接口. 最终排查原因出现在域名上, 在生产环境中通过 java 的 httpclient (该第三方包依赖java.net.URI) 调用未发出请求. 该域名形如 http://test_1.tanglei.name

下面来重现一下该案例.

server 端准备

这里用 nginx 模拟了一下 上文提到的 REST 服务, 假设调用正常返回 "Hello, World\n", nginx 配置如下:

server {
   listen    80;
   server_name test_1.tanglei.name;
   location /testurl {
       add_header Content-Type 'text/plain; charset=utf-8';
       return 200 "Hello, World\n";
   }
}

client

curl 命令

curl 请求

请忽略上面的两个重复的header(nginx 默认有一个header, 上面的配置又加了一个), 可以点击这里查看效果 http://test_1.tanglei.name/testurl. （对，我解析了这个域名）

python requests

python 也是调用OK

java

我们来看一下通过 Java 调用.

上面的这个方法 String getContent(java.net.URL url) 传入一个构造好的 java.net.URL 然后 get 请求, 并以 String 方式返回 response.

String srcUrl = "http://test_1.tanglei.name/testurl";
java.net.URL url = new java.net.URL(srcUrl);
System.out.println("\nurl result:\n" + getContent(url)); // OK

上面的语句输出正常, 结果如下

url result:
Hello, World

换 java.net.URI 试试? (这里不展开讲URL和URI的区别联系了, 可以简单的认为URL是URI的一个子集, 详细的可参考 URI、URL 和 URN, wiki URI) 直接通过java.net.URI构造, 再调用 URI.toURL 得到URL，调用同样正常。关键的来了

URI(String scheme, String host, String path, String fragment)
Constructs a hierarchical URI from the given components.

我用这个方法构造URI, 会构造失败(详细异常信息见文末)。

new java.net.URI(uri.getScheme(), uri.getHost(), uri.getPath(), null) error: protocol = http host = null
new java.net.URI(url.getProtocol(), url.getHost(), url.getPath(), null) error: Illegal character in hostname at index 11: http://test_1.tanglei.name/testurl

所以问题发现了, 我们的项目中依赖的第三方httpclient包底层用到了 java.net.URI, 恰好在 java.net.URI 中是不允许以下划线(_)作为 hostname 字段的。 即这个表达式 uri.getHost() == uri.toURL().getHost() 不一定成立。这是 JDK 的 Bug 吗？

从官网上还真找到了关于包含下划线作为hostname的bug提交ticket, 戳这里 JDK-8132508 : Bug JDK-8029354 reproduces with underscore in hostname ， 然后发现该 “bug” reporter 的情况貌似跟我的差不多，只不过引爆bug的点不一样.

该 “bug” reviewer 最后以 “Not an Issue” 关闭，给出的理由是

RFC 952 disallows _ underscores in hostnames. So, this is not a bug.

确实, rfc952 明确说了域名只能由 字母 (A-Z), 数字(0-9), 减号 (-), 和 点 (.) 组成。

那 OK 吧, 既然明确规定了 hostname 不能包含下划线, 为啥 java.net.URL 确允许呢? 造成 java.net.URI 和 java.net.URL 在处理 hostname 时的标准不一致, 且本身 java.net.URI 在构造的时候也带了 “有色”眼镜, 通过静态方法 java.net.URI.create(String) 或者通过带1个参数的构造方法 java.net.URI(String) 都能成功构造出 URI 的实例，通过带4个参数的构造方法就不能构造了. (同一个url字符串).

要知道, 在 coding 过程中，尽早反馈异常信息更有利于软件开发持续迭代的过程. 我们在开发过程中也应该遵循这一点原则。

JDK(java.net.URL) 中的 “bug” ?

我记得去年我就到JDK官网提交了一个 bug, 大意是说 java.net.URI 和 java.net.URL 在处理hostname的时候标准不一致, 容易使开发人员埋藏一些潜在的bug. 不过当初提交之后就没有反应了。 (为啥没有收到相应的邮件通知 report 状态? 也bug了?)

直到前两天, 又把该问题提交到 stackoverflow.

I am wondering, if hostname with underscore is not valid, why the result is differrent between java.net.URI and java.net.URL? Is it a bug or a feature? Here is the example.

java.net.URL url = new java.net.URL("http://test_1.tanglei.name");
System.out.println(url.getHost()); //test_1.tanglei.name
java.net.URI uri = new java.net.URI("http://test_1.tanglei.name");
System.out.println(uri.getHost()); //null

过了1天才发现原来我去年提交的bug有更新状态了. bug 详细信息见 JDK-8170265 : underscore is allowed in java.net.URL while not in java.net.URI, (openjdk JDK-8170265 更详细）。 然而该 bug 状态也以 “Not an Issue” 告终. 不过其中一个reviewer还是承认了这个问题, 说的是 java.net.URL 遵循的是 RFC 2396 规范, 确实不允许含有下划线的hostname，java.net.URI 做到了， 而 java.net.URL 没有做到。

As per RFC 2396: “Hostnames take the form described in Section 3 of [RFC1034] and Section 2.1 of [RFC1123]: a sequence of domain labels separated by “.”, each domain label starting and ending with an alphanumeric character and possibly also containing “-“ characters. The rightmost domain label of a fully qualified domain name will never start with a digit, thus syntactically distinguishing domain names from IPv4 addresses, and may be followed by a single “.” if it is necessary to distinguish between the complete domain name and any local domain. To actually be “Uniform” as a resource locator, a URL hostname should be a fully qualified domain name. In practice, however, the host component may be a local domain literal.” URI class is following the above, but URL class doesn’t seem to follow the same rules. To reproduce the issue , run the attached test case. Following is the output on various JDK versions: JDK 8 - Fail JDK 8u112 - Fail JDK 8u122-ea - Fail JDK 9-ea + 141 - Fail

重点来了, 然后, 被上一级 reviewer 直接个毙了. 原因是 java.net.URL 构造方法中，api文档中说了本来也不会做验证即 No validation of the inputs is performed by this constructor. 在线 api doc 戳这里 (可以点连接，进去搜索关键字 “No validation”)

The constructors of URL class (e.g., http://download.java.net/java/jdk9/docs/api/java/net/URL.html#URL-java.lang.String-java.lang.String-java.lang.String-) specifically mention about the validation: “No validation of the inputs is performed by this constructor.” So not throwing an exception isn’t an issue here.

其实就算 “No validation of the inputs is performed by this constructor.” 是合理的, 里面也只有3个构造函数有这样的说明，按照这样的逻辑是不是说另外的构造函数有验证呢….. (示例中的默认的构造函数都没有说呀)

这里有java.net.URL 的源码, 看兴趣的同学可以看看.

恩，以上就是结论了。 不过，反正我自己感觉目前Java API 关于这里的设计不太合理, 欢迎大家讨论。(也对SO上某答案表示赞同, 哈哈)

The review is somewhat terse, but the reviewer's point is the URL constructor is behaving in accordance with its specification. Since the specification explicitly states that no validation is performed, this is not a bug in the code. This is indisputable. What he didn't spell out is that fixing this inconsistency (by changing the URL class specification) would break lots of peoples' 20+ year old code Java code. That would be a really bad idea. It can't happen. So ... this inconsistency is a "feature".