有没有办法使用Java 11的HttpClient从HTTP 1.1响应的状态行中获取Reason-Phrase?

huangapple go评论68阅读模式
英文:

Is there a way to fetch the Reason-Phrase from the status line of a HTTP 1.1 response with Java 11's HttpClient?

问题

使用Java的java.net.HttpURLConnection类,有一个getResponseMessage()方法,用于检索任何Reason-Phrase文本(如RFC2616 6.1状态行所指定)。

在更新的Java 11 HttpClient中,java.net.http.HttpResponse类只有一个statusCode()方法。

是否有办法使用此API获取状态行末尾返回的文本?如果没有,为什么没有包括在内?(我知道HTTP 2 未定义此值,但大多数应用仍使用仍然有效的HTTP 1.1。)

英文:

With Java's java.net.HttpURLConnection there is a getResponseMessage() method to retrieve any Reason-Phrase text (as specified by RFC2616 6.1 Status Line).

In the newer Java 11 HttpClient, java.net.http.HttpResponse only has a statusCode() method.

Is there a way to obtain text returned on the end of the status line using this API? If not, why was it not included? (I know that HTTP 2 does not define this value, but most applications still use HTTP 1.1 where it remains valid.)

答案1

得分: 6

是否有一种方法可以通过这个 API 获取返回在状态行末尾的文本?

没有。

如果没有,为什么没有包含它?

我们无法告诉您实际的原因,因为没有发布详细的设计理念。

然而,我想象原因如下:

  1. 因为客户端通常会忽略这些文本。(请容我解释...)

  2. 因为这些文本很少包含任何有用的信息。通常只是与响应代码对应的标准(推荐的)文本消息。(这是为什么客户端通常会忽略这些文本的一个原因。)

  3. 因为如果一个 Web 应用程序要提供有意义的解释,很可能会在有效载荷中进行。 (因为第1点。但也强化了这一点。)

  4. 因为某些 Web 栈不允许 Web 应用设置原因文本。

  5. 因为某些 HTTP 1.1 Web 服务器通常完全省略原因文本! (例如,Tomcat 8.0.x 就没有消息,而 Tomcat 8.5.x 则有一个启用它的选项。)


(我知道 HTTP 2 没有定义这个值,但大多数应用仍然使用仍然有效的 HTTP 1.1。)

现在是这样... <sup>1</sup>。

这实际上是(新的)Web 应用程序不会尝试在原因文本中传递有用信息并且不支持它在 API 中的另一个原因。

最终,大多数应用程序将使用 HTTP 2 或更高版本。或者至少,足够多的应用程序会使用它,以至于依赖于对 HTTP 1.x 功能的良好支持可能会对您的应用程序造成问题。

请记住,HTTP 3 现在正在进行中。没有人能够深入未来,准确预测未来 5 年内有多少比例的 Web 服务器将使用哪些版本的 HTTP。

<sup>1 - 服务器端采用率正在上升,但这取决于服务器平台。有关一些数据,请参阅2020 年 Web 年鉴。</sup>


在上述情况下,如果您的客户端代码依赖于查看特定的原因文本... 或者根本不查看... 那么它很可能会在某些 Web 服务器上出现问题。

因此,我会说 Java 11 的 HttpClient API 设计人员通过不将原因文本暴露给客户端代码为我们所有人做了一个大忙。

您可以不同意... 并使用其他 HTTP 客户端库。


我的建议是顺势而为。如果您不尝试使用原因文本(客户端或服务器端),那么您就不必处理使用它会带来的问题。问题只会变得更糟。

英文:

> Is there a way to obtain text returned on the end of the status line using this API?

No.

> If not, why was it not included?

We can't tell you the actual reasons because a detailed design rationale has not been published.

However, I imagine that the reasons / reasoning went like this:

  1. Because the text is routinely ignored by clients. (Bear with me ...)

  2. Because the text rarely contains anything useful. It is usually just the standard (recommended) text message corresponding to the response code. (This is one reason why the text is routinely ignored by clients.)

  3. Because if a web application is going to provide a meaningful explanation, it is likely to do it in the payload. (Because of 1. But also reinforcing it.)

  4. Because some web stacks don't let the web app set the reason text.

  5. Because some HTTP 1.1 web servers routinely leave the reason text out entirely! (For example, with Tomcat 8.0.x there is no message, and with Tomcat 8.5.x there is an option to enable it.)


> (I know that HTTP 2 does not define this value, but most applications still use HTTP 1.1 where it remains valid.)

That's now ... <sup>1</sup>.

This is actually another reason for (new) web applications not try to pass useful information in the reason text AND to not support it in the API.

Eventually, most applications will use HTTP 2 or later. Or at least, enough will use it that relying on good support for an HTTP 1.x feature could cause problems for your application.

Bear in mind that HTTP 3 is now in the pipeline. Nobody can see far enough into the future to accurately predict what proportion of web servers will use what versions of HTTP in (say) 5 years time.

<sup>1 - Server-side adoption is trending upwards, but it varies depending on the server platform. See the 2020 Web Almanac for some data points.</sup>


In the light of the above, if you make your client code depend on seeing specific reason texts ... or seeing any at all ... then it is liable to break for some web servers.

Hence, I would say that Java 11's HttpClient API designers did us all a big favor by not exposing the reason text to client-side code.

You are free to disagree ... and use other HTTP client libraries.


My advice is to go with the flow. If you don't try to use the reason text (client side or server side) then you won't have to deal with the problems that using it will bring. The problems will only get worse.

答案2

得分: 1

我在Java中寻找HTTP状态代码的原因短语,并在谷歌搜索期间找到了这个讨论。最终,我编写了自己的函数,希望在有人发现它有用时分享出来。它可能不完整,但对我的目的很有帮助。

public static String getReasonPhrase(int statusCode) {
    switch(statusCode) {
        case (200): return "OK";
        case (201): return "Created";
        case (202): return "Accepted";
        case (203): return "Non Authoritative Information";
        case (204): return "No Content";
        case (205): return "Reset Content";
        case (206): return "Partial Content";
        case (207): return "Partial Update OK";
        case (300): return "Mutliple Choices";
        case (301): return "Moved Permanently";
        case (302): return "Moved Temporarily";
        case (303): return "See Other";
        case (304): return "Not Modified";
        case (305): return "Use Proxy";
        case (307): return "Temporary Redirect";
        case (400): return "Bad Request";
        case (401): return "Unauthorized";
        case (402): return "Payment Required";
        case (403): return "Forbidden";
        case (404): return "Not Found";
        case (405): return "Method Not Allowed";
        case (406): return "Not Acceptable";
        case (407): return "Proxy Authentication Required";
        case (408): return "Request Timeout";
        case (409): return "Conflict";
        case (410): return "Gone";
        case (411): return "Length Required";
        case (412): return "Precondition Failed";
        case (413): return "Request Entity Too Large";
        case (414): return "Request-URI Too Long";
        case (415): return "Unsupported Media Type";
        case (416): return "Requested Range Not Satisfiable";
        case (417): return "Expectation Failed";
        case (418): return "Reauthentication Required";
        case (419): return "Proxy Reauthentication Required";
        case (422): return "Unprocessable Entity";
        case (423): return "Locked";
        case (424): return "Failed Dependency";
        case (500): return "Server Error";
        case (501): return "Not Implemented";
        case (502): return "Bad Gateway";
        case (503): return "Service Unavailable";
        case (504): return "Gateway Timeout";
        case (505): return "HTTP Version Not Supported";
        case (507): return "Insufficient Storage";
        default: return "";
    }
}
英文:

I was looking for http status code reason phrases in Java and found this discussion during my Google search. I ended up writing my own function that I wanted to share in case somebody else finds it useful. It might not be complete, but it serves my purposes.

public static String getReasonPhrase(int statusCode) {
switch(statusCode) {
case (200): return &quot;OK&quot;;
case (201): return &quot;Created&quot;;
case (202): return &quot;Accepted&quot;;
case (203): return &quot;Non Authoritative Information&quot;;
case (204): return &quot;No Content&quot;;
case (205): return &quot;Reset Content&quot;;
case (206): return &quot;Partial Content&quot;;
case (207): return &quot;Partial Update OK&quot;;
case (300): return &quot;Mutliple Choices&quot;;
case (301): return &quot;Moved Permanently&quot;;
case (302): return &quot;Moved Temporarily&quot;;
case (303): return &quot;See Other&quot;;
case (304): return &quot;Not Modified&quot;;
case (305): return &quot;Use Proxy&quot;;
case (307): return &quot;Temporary Redirect&quot;;
case (400): return &quot;Bad Request&quot;;
case (401): return &quot;Unauthorized&quot;;
case (402): return &quot;Payment Required&quot;;
case (403): return &quot;Forbidden&quot;;
case (404): return &quot;Not Found&quot;;
case (405): return &quot;Method Not Allowed&quot;;
case (406): return &quot;Not Acceptable&quot;;
case (407): return &quot;Proxy Authentication Required&quot;;
case (408): return &quot;Request Timeout&quot;;
case (409): return &quot;Conflict&quot;;
case (410): return &quot;Gone&quot;;
case (411): return &quot;Length Required&quot;;
case (412): return &quot;Precondition Failed&quot;;
case (413): return &quot;Request Entity Too Large&quot;;
case (414): return &quot;Request-URI Too Long&quot;;
case (415): return &quot;Unsupported Media Type&quot;;
case (416): return &quot;Requested Range Not Satisfiable&quot;;
case (417): return &quot;Expectation Failed&quot;;
case (418): return &quot;Reauthentication Required&quot;;
case (419): return &quot;Proxy Reauthentication Required&quot;;
case (422): return &quot;Unprocessable Entity&quot;;
case (423): return &quot;Locked&quot;;
case (424): return &quot;Failed Dependency&quot;;
case (500): return &quot;Server Error&quot;;
case (501): return &quot;Not Implemented&quot;;
case (502): return &quot;Bad Gateway&quot;;
case (503): return &quot;Service Unavailable&quot;;
case (504): return &quot;Gateway Timeout&quot;;
case (505): return &quot;HTTP Version Not Supported&quot;;
case (507): return &quot;Insufficient Storage&quot;;
default: return &quot;&quot;;
}
}

答案3

得分: 0

正如您注意到的HttpResponse没有提供任何用于获取原因短语的API。没有任何隐藏的方法来获取它。您是否有一个使用案例,需要在HttpResponse中具有原因短语的访问器?

英文:

As you noticed the HttpResponse doesn't provide any API to get the reason phrase. There is no hidden way to get it. Do you have a use case where having an accessor for the reason phrase in HttpResponse would be useful?

huangapple
  • 本文由 发表于 2020年8月23日 03:04:20
  • 转载请务必保留本文链接:https://go.coder-hub.com/63540068.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定