Per spec: http://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#rfc.section.5, we can include Keep-Alive headers in our request Connection: Keep-Alive; Keep-Alive: timeout=100 and hopefully expect a response with Keep-Alive: timeout=15, max=100 back. If there is no Keep-Alive response header, Http client defaults to keeping connections longer by default, however, you can also use a custom strategy to close connections after a custom timeout as we did not get a Connection: close either as discussed here http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html and How to keep HttpClient Connection Keep-Alive?.
In our case, the server neither returns a keep-alive header nor returns a connection: close meaning requests can be kept-alive for some more time.
Does the Http Client take care of such Connection: close cases in future responses from the same reused connection that did not return any time-out header previously? What happens when other side has dropped connection or timeouts on an existing keep alive connection? does it re open another connection or fail on the same connection? What is the best way to handle this?
Is there a better way to handle Keep-Alive connections when DNS entries are updated? I am sure Http Client can theoretically be aware of this change. This is also a very common use case because you typically use a VIP/LB and they point underlying servers to different colo during releases. Again, in this case, all of the keep alive connections will fail, because the state from one colo is not replicated to another. Is there a hook like the IdleConnectionMonitor to check?
Is there a better way for Http Client to automatically add the request header by default: "Keep-Alive","timeout, max=20" based on socket and connection time out settings if Keep Alive is enabled?
We are using httpcomponents httpclient 4.3.6.
