HttpClient如何实现long-link或half-long-link？
How to implement long-link or half-long-link by HttpClient?
我遇到过需要查看订单状态的情况。但是远程服务器不会return很快响应，因为它会花费相对较长的时间。
所以有人推荐我使用HttpClient的long-link或half-long-link。但我从来没有 运行 陷入这样一个未知的境地。所以我想知道如何实现它。有人有什么好主意吗？
如果您的 so-called "long-link" 或 "half-long-link" 表示 "keep-alive"，那么我想我找到了解决方案。有一个名为 "Connection" 的 header，它有两个参数可供选择："Keep-Alive" 或 "close"。在 http 1.0 中，默认为 "close"。但在 Http 1.1 中，"Keep-Alive" 是默认值。所以，如果你想实现一个持久化的link，你需要在这些请求执行之前调用HttpGet/HttpPost/HttpPut的setRequestHeader("Connection" , "Keep-Alive")的方法
同时，下面可能你已经知道了，希望对你有所帮助：
Http Keep-Alive seems to be massively misunderstood. Here's a short
description of how it works, under both 1.0 and 1.1.
HTTP/1.0
Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request: Connection: Keep-Alive Then, when the server receives this request and generates a response, it also adds a header to the response:
Connection: Keep-Alive Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.
HTTP/1.1
Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header: Connection: close The Connection: Keep-Alive header no longer has any meaning because of this. Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it. Not reliable HTTP is a stateless protocol - this means that every request is independent of every other. Keep alive doesn’t change that.
Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that the connection is being closed. So keepalive is something you should not write your application to rely upon. KeepAlive and POST The HTTP 1.1 spec states that following the body of a POST, there are to be no additional characters.
It also states that "certain" browsers may not follow this spec, putting a CRLF after the body of the POST. Mmm-hmm. As near as I can tell, most browsers follow a POSTed body with a CRLF. There are two ways of dealing with this: Disallow keepalive in the context of a POST request, or ignore CRLF on a line by itself. Most servers deal with this in the latter way, but there's no way to know how a server will handle it without testing.
我遇到过需要查看订单状态的情况。但是远程服务器不会return很快响应，因为它会花费相对较长的时间。
所以有人推荐我使用HttpClient的long-link或half-long-link。但我从来没有 运行 陷入这样一个未知的境地。所以我想知道如何实现它。有人有什么好主意吗？
如果您的 so-called "long-link" 或 "half-long-link" 表示 "keep-alive"，那么我想我找到了解决方案。有一个名为 "Connection" 的 header，它有两个参数可供选择："Keep-Alive" 或 "close"。在 http 1.0 中，默认为 "close"。但在 Http 1.1 中，"Keep-Alive" 是默认值。所以，如果你想实现一个持久化的link，你需要在这些请求执行之前调用HttpGet/HttpPost/HttpPut的setRequestHeader("Connection" , "Keep-Alive")的方法
同时，下面可能你已经知道了，希望对你有所帮助：
Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both 1.0 and 1.1.
HTTP/1.0
Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request: Connection: Keep-Alive Then, when the server receives this request and generates a response, it also adds a header to the response:
Connection: Keep-Alive Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.
HTTP/1.1
Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header: Connection: close The Connection: Keep-Alive header no longer has any meaning because of this. Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it. Not reliable HTTP is a stateless protocol - this means that every request is independent of every other. Keep alive doesn’t change that.
Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that the connection is being closed. So keepalive is something you should not write your application to rely upon. KeepAlive and POST The HTTP 1.1 spec states that following the body of a POST, there are to be no additional characters.
It also states that "certain" browsers may not follow this spec, putting a CRLF after the body of the POST. Mmm-hmm. As near as I can tell, most browsers follow a POSTed body with a CRLF. There are two ways of dealing with this: Disallow keepalive in the context of a POST request, or ignore CRLF on a line by itself. Most servers deal with this in the latter way, but there's no way to know how a server will handle it without testing.