Jaikiran, > On 2 Jun 2018, at 07:22, Jaikiran Pai <jai.forums2...@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/
