RE: HTTP client API

.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Michael McMahon Sent: Tuesday, November 29, 2016 10:47 AM To: Tobias Thierer Cc: OpenJDK Network Dev list Subject: Re: HTTP client

Re: HTTP client API

Hi Tobias, Apologies for the long delay in responding. I'll hopefully catch up on your subsequent comments soon. Just to give an overall update on the status of this work first. There is a plan afoot to make the JDK 9 module system support something we are calling "incubator modules". These ar

Re: HTTP client API

Tobias, If you look at the code in the sandbox [*], the notion of a default client has been removed. Having global static default instances is problematic. Http Clients are lightweight, easy to configure and pass around, if that is what you want. -Chris. [*] hg clone http://hg.openjdk.java.net/

Re: HTTP client API

Hi Michael - Some follow-up/updates on items from my previous email inline below: On Mon, Oct 31, 2016 at 6:13 PM, Tobias Thierer wrote: > > On Fri, Oct 28, 2016 at 12:28 PM, Michael McMahon < > michael.x.mcma...@oracle.com> wrote: > >> >> The intention behind those interfaces is primarily to p

Re: HTTP client API

On Mon, Oct 31, 2016 at 6:13 PM, Tobias Thierer wrote: > On Fri, Oct 28, 2016 at 12:28 PM, Michael McMahon < > michael.x.mcma...@oracle.com> wrote: >> >> 2.) HttpHeaders: I love that there is a type for this abstraction! But: >> >>- >> >>Why is the type an interface rather than a concrete

Re: HTTP client API

Hi Michael - thanks a lot for your response! Further comments below. How would you rank simplicity, versatility and performance as goals for the HTTP Client API? For example the blocking vs. non-blocking API choices will largely depend on trade-offs, so I'd like to understand the target applicati

Re: HTTP client API

Hi Tobias Thanks for the feedback (and thanks to Anthony for answering some of the questions) My thoughts are below. On 24/10/2016, 20:33, Tobias Thierer wrote: Hi Michael and others - Thanks for publishing the latest HTTP client API docs

Re: HTTP client API

Hi Tobias As far as I know, the latest published Javadoc is at [1] (which was linked to in [2]). However, this Javadoc doesn't exactly match the current code either. Below are some quick replies to some of your feedback. 1.) > What is the advantage of the Publisher / Subscriber API over pla

Re: HTTP client API

On 22/09/16 08:54, Chris Hegarty wrote: On 22 Sep 2016, at 00:14, Michael McMahon wrote: Martin The source is available in the JDK 9 sandbox (http-client-branch) at http://hg.openjdk.java.net/jdk9/sandbox/ I think it has been updated to reflect the API as described below. Apologies, it has

Re: HTTP client API

On 22 Sep 2016, at 00:14, Michael McMahon wrote: > > Martin > > The source is available in the JDK 9 sandbox (http-client-branch) at > http://hg.openjdk.java.net/jdk9/sandbox/ > > I think it has been updated to reflect the API as described below. Apologies, it has not been update yet. I will d

Re: HTTP client API

Martin The source is available in the JDK 9 sandbox (http-client-branch) at http://hg.openjdk.java.net/jdk9/sandbox/ I think it has been updated to reflect the API as described below. Michael. On 21/09/2016, 14:14, Martin Buchholz wrote: On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon mai

Re: HTTP client API

On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon < michael.x.mcma...@oracle.com> wrote: > > [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/ > > [2] http://cr.openjdk.java.net/~michaelm/httpclient/ > specdiffout.1/package-summary.html > Could we have actual source code for experimentati

Re: HTTP client API

Hi Anthony, On 08/09/2016, 18:49, Anthony Vanelverdinghe wrote: Hi Michael What's the rationale for not turning all public classes into interfaces, since none of them contain any actual implementation code? We could do that with little or no impact on the implementation or on calling code.

Re: HTTP client API

Hi Michael What's the rationale for not turning all public classes into interfaces, since none of them contain any actual implementation code? On another note, I fail to see the point of HttpClient.Builder::priority: as far as I understand, HTTP/2 priority only comes into play when multiple

Re: HTTP client API

Hi Wenbo, First, sorry for the delay in replying. We took your comments and prototyped how the major ones might be accommodated. In particular, we did the following: - moved "business logic" out of HttpRequest. The methods for sending requests now exist in HttpClient. Given that requests a

Re: HTTP client API

Martin, Wenbo, We are considering the feedback, will take it under advisement, and reply in due course. -Chris. > On 26 Aug 2016, at 22:14, Martin Buchholz wrote: > > I don't know much about http, but I believe those who say that it's very hard > to get the API right. Perhaps it would be bes

Re: HTTP client API

I don't know much about http, but I believe those who say that it's very hard to get the API right. Perhaps it would be best to deliver a http client library as an independent beta package for use with jdk 8+ with a final version becoming part of jdk 10? Perhaps there can be a productive collabor

Re: HTTP client API

On 23/08/16 22:19, Pavel Rappo wrote: http://cr.openjdk.java.net/~chegar/docs/sandbox.html And yes, 'http-client-branch' is the correct branch. -Chris. On 23 Aug 2016, at 21:20, Martin Buchholz wrote: I tried this: (Install mercurial trees extension.) hg tclone http://hg.openjdk.java.n

Re: HTTP client API

http://cr.openjdk.java.net/~chegar/docs/sandbox.html > On 23 Aug 2016, at 21:20, Martin Buchholz wrote: > > I tried this: > > (Install mercurial trees extension.) > hg tclone http://hg.openjdk.java.net/jdk9/sandbox jdk9-sandbox > hg tupdate -r http-client-branch > > Is that right? > I'm not

Re: HTTP client API

On Tue, Aug 23, 2016 at 12:57 PM, Wenbo Zhu wrote: > >> We are currently working in the sandbox repository again and will have >> these changes >> in the main JDK9 dev forest soon. >> > Is it possible to access the API code somewhere before then, mainly as a > convenience for reviewing the APIs?

Re: HTTP client API

On Mon, Aug 22, 2016 at 12:56 AM, Michael McMahon < michael.x.mcma...@oracle.com> wrote: > There is an updated version of the HTTP client API doc [1] and a specdiff > [2] showing the changes > proposed from the current version in JDK9 dev. > > The main changes are: > > 1) The request and response

Re: Http client API

On 17.08.2012 14:30, Michael McMahon wrote: On 09/08/12 19:15, Chris Hegarty wrote: Michael, Looking good, some comments. 1) Why the use of CookieManager, rather than CookieHandler? I would expect that CookieHandler would be a cleaner API CookieHandler is a very low level API, which doesn't

Re: Http client API

On 17/08/12 11:59, Frank Carver wrote: On 17 August 2012 11:30, Michael McMahon wrote: 2) What is the impact on the sendHeader, setBody for HEAD requests? Ah yes, HEAD needs special treatment - though not with respect to the methods above as HEAD is identical to GET except with respect to any

Re: Http client API

On 17 August 2012 11:30, Michael McMahon wrote: >> 2) What is the impact on the sendHeader, setBody for HEAD requests? > Ah yes, HEAD needs special treatment - though not with respect to the methods > above as HEAD is identical to GET except with respect to any returned > response body. > > So,

Re: Http client API

Chris, Thanks for the comments. Some responses below: On 09/08/12 19:15, Chris Hegarty wrote: Michael, Looking good, some comments. 1) Why the use of CookieManager, rather than CookieHandler? I would expect that CookieHandler would be a cleaner API CookieHandler is a very low level A

Re: Http client API

On 08/08/12 20:09, Ian Robertston wrote: Instead of HttpRequest having void setBody(Iterable buffers, boolean isRestartable) what about having two methods: void setBody(Iterable buffers) // presumed restartable void setBody(Iterator buffers) // clearly not restartable Not only doe

Re: Http client API

On 15/08/12 16:59, Mike Duigou wrote: On Aug 15 2012, at 09:06 , Michael McMahon wrote: HttpClientProvider:: - HttpClientProvider JavaDoc uses inconsistent capitalization of HTTP. - createAsynchronousHttpClient() Since there's only one create method why bother to mention that it's "Asynchron

Re: Http client API

On 15/08/2012 16:59, Mike Duigou wrote: On Aug 15 2012, at 09:06 , Michael McMahon wrote: : Yes, the provider needs work. I agree with the above. Though I don't know about the necessity to provide multiple alternate providers. If there is only ever going to be one provider then why include a

Re: Http client API

On Aug 15 2012, at 09:06 , Michael McMahon wrote: >> HttpClientProvider:: >> >> - HttpClientProvider JavaDoc uses inconsistent capitalization of HTTP. >> >> - createAsynchronousHttpClient() Since there's only one create method why >> bother to mention that it's "Asynchronous"? >> >> - It's no

Re: Http client API

On 09/08/12 01:49, David M. Lloyd wrote: On 08/07/2012 06:09 PM, Michael McMahon wrote: Hi, A new revision of the Http client API planned for jdk 8 can be viewed at the following link http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ We would like to review the api on this mailing list. S

Re: Http client API

Just as a reminder, for reading the response, we had originally decided to simply terminate whatever bytebuffer/byte arrays we have with a -1 to indicate EOF. But if returning the number of bytes read results in cleaner code, maybe we should do this. HttpResponse:: - getBodyAsBytes(byte[],

Re: Http client API

- HttpClient createClient() -- is this the same as HttpClientProvider.provider().createAsynchronousHttpClient()? yes, and that needs to be documented. Just on this one, the method name createAsynchronousHttpClient() looks like a remnant of our previous API iterations, and I think this should

Re: Use Builder pattern ( was: Re: Http client API)

On 09/08/12 10:50, Chris Hegarty wrote: On 09/08/12 00:00, Jed Wesley-Smith wrote: Michael McMahon writes: A new revision of the Http client API planned for jdk 8 can be viewed at the following link http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ We would like to review the api on thi

Re: Http client API

Mike. Thanks for the comments. I have commented on most of your points. There are a few I'm not sure about, and maybe others will chime in. - Michael. On 08/08/2012 23:33, Mike Duigou wrote: General:: - It's probably already been mentioned but having the classes in the httpclient package and

Re: Http client API

On Aug 14, 2012, at 8:49 PM, Michael McMahon wrote: > Xuelei, > > We have no particular requirement on HostnameVerifier. So, > if I understood you correctly, HostnameVerifier is redundant in new APIs > and it is possible to control hostname verification through the SSLParameters > class > (and

Re: Http client API

Xuelei, We have no particular requirement on HostnameVerifier. So, if I understood you correctly, HostnameVerifier is redundant in new APIs and it is possible to control hostname verification through the SSLParameters class (and an X509ExtendedTrustManager). So, we can drop HostnameVerifier fr

Re: Http client API

To everyone who has commented on the API so far, thank you! It is much appreciated. We will be getting back on all the issues raised in the coming days. I am just about to send out a request on jdk8-dev (which covers all JDK groups) to solicit feedback from as many people as possible. Thanks

Re: Http client API

Michael, Looking good, some comments. 1) Why the use of CookieManager, rather than CookieHandler? I would expect that CookieHandler would be a cleaner API 2) What is the impact on the sendHeader, setBody for HEAD requests? 3) I think HttpClient could be an interface and move the create me

Re: Http client API

Wow, Mike. Great feedback. I just scanned your comments, and agree/understand most of them. I'll help Michael to feed them back into the API. Though, there'll probably be a few follow up mails to answers your direct questions and seek further clarification before the new rev of the API. Than

Re: Http client API

On 09/08/12 06:10, Sean Chou wrote: Hi Chris, That's exactly my concern. I agree this provides best flexibility and content convenient methods are not proper in this API. So, is there going to have content specific convenient APIs like java.nio.file.Files ? Although it is a wrapper, it may

Use Builder pattern ( was: Re: Http client API)

On 09/08/12 00:00, Jed Wesley-Smith wrote: Michael McMahon writes: A new revision of the Http client API planned for jdk 8 can be viewed at the following link http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ We would like to review the api on this mailing list. So, all comments are welc

Re: Http client API

On 09/08/2012 01:49, David M. Lloyd wrote: On 08/07/2012 06:09 PM, Michael McMahon wrote: Hi, A new revision of the Http client API planned for jdk 8 can be viewed at the following link http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ We would like to review the api on this mailing list.

Re: Http client API

Hi Chris, That's exactly my concern. I agree this provides best flexibility and content convenient methods are not proper in this API. So, is there going to have content specific convenient APIs like java.nio.file.Files ? Although it is a wrapper, it may be useful and intuitive, and easy to u

Re: Http client API

On 08/07/2012 06:09 PM, Michael McMahon wrote: Hi, A new revision of the Http client API planned for jdk 8 can be viewed at the following link http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ We would like to review the api on this mailing list. So, all comments are welcome. Why not jav

Re: Http client API

Michael McMahon writes: > A new revision of the Http client API planned for jdk 8 can be viewed > at the following link > > http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/ > > We would like to review the api on this mailing list. > So, all comments are welcome. Can you separate the domai

Re: Http client API

Hi Michael! I really look forward to using this API! It looks like you have made a lot of progress. Sorry for having so many comments on just one round. Mike General:: - It's probably already been mentioned but having the classes in the httpclient package and most of them begin with "Http" see

Re: Http client API

Oh, my head hurts! ;-) There are already three setBody methods. I agree, a boolean like this can be confusing. A setBodyRestartable(Itr), and setBodyNonRestarable(Itr) may be a possible solution here. But ( what I think you are suggesting too ), Iterable implementations should do the right th

Re: Http client API

Instead of HttpRequest having void setBody(Iterable buffers, boolean isRestartable) what about having two methods: void setBody(Iterable buffers) // presumed restartable void setBody(Iterator buffers) // clearly not restartable Not only does this avoid a potentially confusing boolean par

Re: Http client API

Hi With the current API (java.net.HttpURLConnection) it 's not possible to follow redirects from one protocol to another (http to https & vice versa). This is a known problem ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4620571 ), but out of security concerns this feature was not added

Re: Http client API

>From JDK 7, JSSE introduces a new hostname verifying approach. It is call "endpoint identification" in JSSE context. It can be used to replace the HostnameVerifier on SSLSession. A typical user case looks like: 1. implement a X509ExtendedTrustManager. It is required to check the endpoint identifi

Re: Http client API

On 08/08/2012 07:25, Sean Chou wrote: Is it possible to have methods like public abstract HTMLDocument getResponse(String request) in class HttpClient ? I see Chris has replied to this. One other point is that we also need to consider JDK modularization and I don't think we should have any

Re: Http client API

On 08/08/2012 07:25, Sean Chou wrote: Is it possible to have methods like public abstract HTMLDocument getResponse(String request) in class HttpClient ? Hi Sean, I think what you are suggesting is content specific convenience methods, something akin to URLConnection.getContent(), right? In

Re: Http client API

Is it possible to have methods like public abstract HTMLDocument getResponse(String request) in class HttpClient ? On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon < michael.x.mcma...@oracle.com> wrote: > Hi, > > A new revision of the Http client API planned for jdk 8 can be viewed > at the fo