Connection: close means, it wants that client must be close the
connection when receive the chunked data. Am I right?
Not exactly. A Connection: close header in an HTTP message is informative, not prescriptive. It advises the receiver that the server intends to close the connection after sending the response (see RFC 7230, section 6.1). The user is not obligated to take specific action in response, but it may save itself some time by not attempting any further communication over that connection after receiving the HTTP payload. In practice, however, yes, after receiving the response, the client should close the application-layer connection on its end, too, for until it does, it will tie up associated system resources for no good reason.
But none of that is really your concern if you're working with an HttpURLConnection and / or the InputStream obtained from one. Per its documentation:
Each HttpURLConnection instance is used to make a single request but
the underlying network connection to the HTTP server may be
transparently shared by other instances. Calling the close() methods
on the InputStream or OutputStream of an HttpURLConnection after a
request may free network resources associated with this instance but
has no effect on any shared persistent connection. Calling the
disconnect() method may close the underlying socket if a persistent
connection is otherwise idle at that time.
That is, HttpURLConnection manages the details of persistent connections for you.
You continue,
Or, connection not closed because of data is streaming(server sends
chunked data each time, I'm not send get request to the server at each
time. Or is this done in the background?).
It seems that you simply mean that the server does not specify a content-length, and sends a response of indeterminate length over an extended period of time. In that case, the Connection header probably hasn't much practical relevance.
So, connection is not
closing at any time until I close the inputStream.close() method.
Right?
The server will not ordinarily close the connection at its end until it has sent the complete response. If, in principle, the response has unbounded length, then there is no reason to expect the server to initiate a connection closure from its end other than server shutdown or failure.
Also, if server is down at any time, http url connection will be
thrown the IOException.
Maybe. If the attempt to establish a connection in the first place fails, then you can expect an IOException of some flavor. If the server goes down while delivering the response then you might get an exception, but you might also just see the end of the stream.
In this case, Must I call the disconnect()
method of the http url connection? Or, should I call just
inputStream.close()?
You do not ever need to disconnect(), and if you do then it is merely advisory, as described in the docs quoted above. If you reach the end of the stream then you should indeed close it. If an IOException is thrown while you are reading the stream then it's probably best to attempt to close() the stream, but be prepared for that to fail, too, as the stream might be in an inconsistent state.
How can I close the http url connection safely at any time?
Once you've actually connected an HttpURLConnection instance to the underlying resource, closing its stream(s) should be enough to indicate that you're done with it. Before you've connected, you don't need to do anything at all.
