HttpClient API usage feedback/questions

[Chris Hegarty]

Jaikiran,

> On 2 Jun 2018, at 07:22, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> Hello,
> 
> I've been experimenting with the new HttpClient API that's part of Java now. I am using the latest EA build 16 of Java 11 from here[1]. I'm still in the early stages of integrating this into one of the libraries where we use HTTP clients.
> 
> Based on my usage so far, I have some minor feedback/questions/enhancement requests that I would like input on:
> 
> 1. The java.net.http.HttpHeaders has firstValue and firstValueAsLong APIs which return an empty Optional if those headers are absent. Would it be possible to introduce a couple of additional APIs of the form:
> 
> String firstValueOrDefault(String name, String defaultValue) // return the actual header value if present, else return the passed default value
> 
> long firstValueAsLongOrDefault(String name, long defaultValue) // return the actual header value, as long, if present, else return the passed default value
> 
> Some of the places where we parse the (response) headers, we check for the presence of some headers and if not present then we default them to certain values (based on certain application specific context). In its current form of the HttpHeaders API, we would either have to write some kind of wrapper API which returns a default value for those headers or keep repeating the logic of checking the returned Optional for empty value, before defaulting it to something.

Already answered.

> 2. Would it be a good idea to add APIs (perhaps in HttpHeaders class) to return values of higher level constructs represented by the headers. Imagine certain well-known headers in the response, like Content-Length and Content-Type. Would it be a good idea to expose higher level APIs of the form getContentLength(), getContentCharset() and such? It probably doesn't add much value to Content-Length header but there's a particular mechanism the charset is supposed to be parsed out of the "Content-Type" header and having it done with the API's implementation would prevent all the parsing/logic in every other application.

Already answered.

> 3. Is the latest API javadoc this one[2]? Based on what I read and experimented so far, I don't see a way to set a value for User-Agent at the HttpClient level. Unless of course, I'm expected to keep setting it on each request that I build in the application? Given that typically, the user agent doesn't change across requests for a particular client, would it be feasible to introduce a way to set this up for each HttpClient?

The following issue tracks a request to be able to set the User-Agent.
  https://bugs.openjdk.java.net/browse/JDK-8203771

Since this is not likely a common operation then setting it through a
specific request header should be sufficient. If experience shows it to
be a pain point then an HttpClient-level configuration could be added in
the future.

> 4. The javadocs currently don't mention anything about connection/resource management within the HttpClient. The only mention I found was here[3] which states:
> 
>  "An HttpClient provides configuration information, and resource sharing, for all requests send through it."
> 
> I'm guessing the resource sharing implies connection reuse?

Correct.

> How long are these (internal) resources maintained?

It is implementation specific. Depends on the protocol, HTTP/1.1 or
HTTP/2. The HTTP/1.1 keep-alive timeout can be set through the
JDK-specific system property, `jdk.httpclient.keepalive.timeout`. The
default timeout is 1200 seconds, and can be large(ish) since the
underlying channel remains registered with the selector and therefore
observes closures.

> Should the users of HttpClient be bothered about it?

I believe not, No.

> The reason I ask is, I don't see a "close()" kind of API on the HttpClient. Does it mean that the internal resource management isn't expected to be tied to the usage of the HttpClient instance?

Having an explicit close on such an asynchronous API is problematic; how
does one know when to call close? As such there is no explicit way to
close an HttpClient, instead all resources associated with a client
instance are automatically cleaned up, through a java.lang.ref.Cleaner,
when the HttpClient is eligible for Cleaning.

Resource sharing is on a per-client basis. To share resources across
multiple contexts, then share the client across said contexts
explicitly.

--- 

We continue to develop the latest HTTP Client code in the sandbox [1],
and expect to bring a number of changes into the mainline, jdk/jdk repo,
soon.

-Chris.

[1] http://openjdk.java.net/groups/net/httpclient/