使用此API获取状态行末尾返回的文本有什么方法吗?
没有。
如果没有,为什么没有包含在内?
我们无法告诉您实际原因,因为详细的设计理念尚未发布。
然而,我想原因可能是这样的:
由于客户通常会忽略文本。(请耐心等待...)
因为文本很少包含有用的内容。它通常只是响应代码对应的标准(推荐)文本消息。(这是文本经常被客户忽略的原因之一。)
因为如果一个Web应用程序要提供有意义的解释,它很可能会在有效载荷中进行。(因为1. 但也加强了这一点。)
因为有些Web堆栈不允许Web应用程序设置原因文本。
因为一些HTTP 1.1 Web服务器通常完全省略原因文本!(例如,在Tomcat 8.0.x中没有消息,在Tomcat 8.5.x中有启用它的选项。)
(我知道HTTP 2没有定义这个值,但大多数应用程序仍在使用HTTP 1.1,其中它仍然有效。)
那现在就是...
1。
这实际上是新的Web应用程序不尝试通过原因文本传递有用信息并且不支持API中的原因文本的另一个原因。
最终,大多数应用程序将使用HTTP 2或更高版本。或者至少足够多的应用程序会使用它,以至于依赖于对HTTP 1.x特性的良好支持可能会导致您的应用程序出现问题。
请记住,HTTP 3现在正在进行中。没有人能够看得太远,准确预测Web服务器将在5年内使用哪些版本的HTTP的比例。
1-服务器端采用率呈上升趋势,但具体取决于服务器平台。请参阅2020 Web Almanac了解一些数据点。
鉴于上述情况,如果您让客户端代码依赖于查看特定原因文本...或根本不查看...那么它可能会在某些Web服务器上出现故障。
因此,我认为Java 11的HttpClient API设计者们通过不向客户端代码公开原因文本给我们所有人带来了巨大的好处。
您可以自由地持不同意见...并使用其他HTTP客户端库。
我的建议是顺其自然。如果你不尝试使用理由文本(客户端或服务器端),那么你就不必处理使用它会带来的问题。问题只会变得更糟。
HttpUrlConnection
等不太可能支持HTTP 2。请阅读JEP 110。我的看法是,他们认为HttpUrlConnection
是遗留问题...就像旧的Java日期/时间和java.io.File
一样。 - Stephen C