我出息了，给 JDK 上报了一个 BUG

最新推荐文章于 2024-09-13 21:40:38 发布

2401_84046635

最新推荐文章于 2024-09-13 21:40:38 发布

阅读量828

点赞数 8

分类专栏：程序员文章标签： java bug python

本文链接：https://blog.csdn.net/2401_84046635/article/details/138038427

版权

程序员专栏收录该内容

444 篇文章 1 订阅

订阅专栏

不同的 client 请求

下面用不同的 Http client （分别用命令行curl，python的 requests包，和 Java 的 URL 等尝试）去请求。

curl 请求，正常。

[root@VM_77_245_centos vhost]# curl -i “http://test_1.tanglei.name/testurl”

HTTP/1.1 200 OK

Server: nginx

Content-Length: 13

Connection: keep-alive

Content-Type: text/plain; charset=utf-8

Hello, World

[root@VM_77_245_centos vhost]#

python requests 正常。

import requests

r = requests.get(“http://test_1.tanglei.name/testurl”)

r.text

u’Hello, World\n’

Java 的 java.net.URLConnection 同样正常。

static String getContent(java.net.URL url) throws Exception {

java.net.URLConnection conn = url.openConnection();

java.io.InputStreamReader in = new java.io.InputStreamReader(conn.getInputStream(), “utf-8”);

java.io.BufferedReader reader = new java.io.BufferedReader(in);

StringBuilder sb = new StringBuilder();

int c = -1;

while ((c = reader.read()) != -1) {

sb.append((char)c);

}

reader.close();

in.close();

String response = sb.toString();

return response;

}

上面的这个方法 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

这就尼玛神奇了吧。看看我们程序中用的 httpclient 的实现，结果发现是有用 java.net.URI，心想，这不至于吧，用 URI 就不行了么。

换 java.net.URI 试试? （这里不展开讲URL和URI的区别联系了，可以简单的认为URL是URI的一个子集，详细的可参考 URI、URL 和 URN[1], wiki URI[2]）

直接通过java.net.URI构造，再调用 URI.toURL 得到 URL，调用同样正常。

关键的来了，httpclient 源码中用的构造函数是另外一个：

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 吧？

有理由怀疑，这是 JDK 的 Bug 吧？

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

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

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

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

那 OK 吧，既然明确规定了 hostname 不能包含下划线，为啥 java.net.URL 确允许呢？

造成 java.net.URI 和 java.net.URL 在处理 hostname 时的标准不一致，且本身 java.net.URI 在构造的时候也带了 "有色"眼镜，同一个url字符串通过静态方法 java.net.URI.create(String) 或者通过带1个参数的构造方法 java.net.URI(String) 都能成功构造出 URI 的实例，但通过带4个参数的构造方法就不能构造了。

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

于是我就去 JDK 官网提交了一个 bug，大意是说 java.net.URI 和 java.net.URL 在处理hostname的时候标准不一致，容易使开发人员埋藏一些潜在的bug，同时也还把这个问题反馈到 stackoverflow[5] 了

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.