Thanks for the updates, Chris. This looks fine to me (I'm not a reviewer).
-Jaikiran
On 07/08/18 3:22 PM, Chris Hegarty wrote:
>> On 4 Aug 2018, at 14:08, Jaikiran Pai wrote:
>>
>> ...
>>
>> Do you think this can be reworded a bit? Although I understand what's
>> being said here, the wording do
The updated webrev looks fine to me, Chris.
Thanks,
Michael
On 07/08/2018, 10:52, Chris Hegarty wrote:
On 4 Aug 2018, at 14:08, Jaikiran Pai wrote:
...
Do you think this can be reworded a bit? Although I understand what's
being said here, the wording doesn't seem right. Maybe something like:
> On 4 Aug 2018, at 14:08, Jaikiran Pai wrote:
>
> ...
>
> Do you think this can be reworded a bit? Although I understand what's
> being said here, the wording doesn't seem right. Maybe something like:
>
> * In the case where a new connection needs to be
> established, if
>
Hi Chris,
src/java.net.http/share/classes/java/net/http/HttpClient.java
+ * In the case where a new connection needs to be
established, if
+ * the connection cannot be established within the given {@code
+ * duration}, then an {@link HttpConnectTimeoutException} is thrown
Hi,
This is a code review to add connection specific timeout support to the
new HTTP Client, as discussed recently over on another thread [1].
The connection timeout duration is proposed to be added at the level of
the client, and if specified applies to all requests sent by that
client. The conn
Hi,
I just want to confirm the plans for the HTTP client API in JDK 9 that
were hinted at previously. There is a new feature called "incubator
modules" which has just been proposed for JDK 9. The idea is to
accommodate new APIs in JDK which are not quite ready to be standardized
es". These are
modules that
can be delivered with the JDK, but are not standard parts of the platform (Java
SE). So, they do not
resolve by default and will have runtime/compile time warnings to indicate that
the contained APIs
are potentially subject to change. The plan is to make this new
s".
These are modules that
can be delivered with the JDK, but are not standard parts of the
platform (Java SE). So, they do not
resolve by default and will have runtime/compile time warnings to
indicate that the contained APIs
are potentially subject to change. The plan is to make this new h
/jdk9/sandbox; cd sandbox
bash common/bin/hgforest.sh update http-client-branch
On 21/11/16 11:28, Tobias Thierer wrote:
Replying to my own first email in this thread to add another question /
concern about flexibility of the HTTP Client API:
Have you considered offering applications a way
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
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
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 t
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
<http://cr.openjdk.java.net/%7Emicha
r wrote:
Hi Michael and others -
Thanks for publishing the latest HTTP client API docs
<http://cr.openjdk.java.net/%7Emichaelm/httpclient/api/>(already
slightly outdated again), as well as for publishing the current draft
code in the sandbox repository!
Below is some concrete f
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
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
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
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
flow-control is very hard to get right).
Attached is a feedback doc on this new version. One specific idea to
discuss is whether it's possible to release the new HTTP client API
as a standalone library (that works on JDK 9).
Thanks,
Wenbo
On Mon, Aug 22, 2016 at 12:56 AM, Michae
6, 07:59, Wenbo Zhu wrote:
Hi Michael,
Thanks for the update! The adoption of the Flow API is indeed a big
improvement (async flow-control is very hard to get right).
Attached is a feedback doc on this new version. One specific idea to
discuss is whether it's possible to release the new
t right).
Attached is a feedback doc on this new version. One specific idea to
discuss is whether it's possible to release the new HTTP client API as
a standalone library (that works on JDK 9).
Thanks,
Wenbo
On Mon, Aug 22, 2016 at 12:56 AM, Michael McMahon
mailto:michael.x.mcma...@or
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
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
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
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
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?
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:
>
>
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 processors are now based on Flow.Publisher
and Flow.Subscriber
2) Response bodies are retrieved
Hi,
I have just posted another draft of the http client API for review.
This will be the final round of review before we submit it to the CCC.
It can be seen at:
http://cr.openjdk.java.net/~michaelm/httpclient/CCCv1.1/javadoc/
Probably the biggest change is that we removed the multiple
build something with it, which I'd be
happy to give a try at.
Thanks
Richard
On Aug 14, 2012, at 5:01 AM, Michael McMahon
wrote:
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http client API [1] for JDK 8.
This message has been cc'd to jdk8-dev
Hello,
I have just posted the javadoc for v 0.4 of the Http client API [1]
This draft takes into account almost all of the feedback from
the last round of reviews. There are a small number of issues
still outstanding however.
For those who are not aware, the development work done so
far has
On 23/08/2012 16:34, Paul Sandoz wrote:
...
OK, i would be inclined to separate out the instance used for building from the
instance passed around, so one cannot muck around with the state of the latter.
Agreed, HttpResponse could use a builder pattern.
Then user code may do:
AsyncHttp
Reader {
>> U read(T t) throws IOException;
>> }
>>
>> Of course i might be missing something obvious here in terms of optimisation
>> currently performed by the implementation!
>>
>> --
>>
>> It somewhat bugs me that blocking and asynchrono
On Aug 23, 2012, at 5:05 PM, Chris Hegarty wrote:
> Paul,
>
> All good feedback, and I will leave it to Michael to reply to the specifics.
> On thought I had on separation of modes is something list this:
>
> interface HeaderHandler {
> onHeaders(HttpResponse);
> }
> interface ErrorHa
We have just published a draft of a proposed new Http client API [1] for JDK 8.
This message has been cc'd to jdk8-dev so that as many people as possible
know about it, but the discussion will be on the net-dev list
(net-dev@openjdk.java.net).
So, folks will have to join that list [2], in
ts. But, my imagination is currently is
failing me on how to improve on such matters. Perhaps something better may come
out of fluent-based API?
Paul.
On Aug 14, 2012, at 2:01 PM, Michael McMahon
wrote:
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http
me on how to improve on such matters. Perhaps something better may come
out of fluent-based API?
Paul.
On Aug 14, 2012, at 2:01 PM, Michael McMahon
wrote:
> Hi,
>
> (apologies for sending this again)
> We have just published a draft of a proposed new Http client API [1] for JDK
ning.
We need to ensure that our pipe-lining API is not restricted to only
Http 1.1 pipe-lining
Are you aware of other areas that could have an impact on the API?
Thanks
Michael.
Sam
On Tue, Aug 14, 2012 at 5:01 AM, Michael McMahon
wrote:
Hi,
(apologies for sending this again)
We have just publ
ot restricted to only
Http 1.1 pipe-lining
Are you aware of other areas that could have an impact on the API?
Thanks
Michael.
Sam
On Tue, Aug 14, 2012 at 5:01 AM, Michael McMahon
wrote:
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http client API [1]
for
hanks
Michael.
Sam
On Tue, Aug 14, 2012 at 5:01 AM, Michael McMahon
wrote:
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http client API [1]
for JDK
8.
This message has been cc'd to jdk8-dev so that as many people as
possible
know about it,
McMahon
wrote:
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http client API [1]
for JDK
8.
This message has been cc'd to jdk8-dev so that as many people as
possible
know about it, but the discussion will be on the net-dev list
(net-dev@openjdk.j
14, 2012 at 5:01 AM, Michael McMahon
wrote:
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http client API [1] for JDK
8.
This message has been cc'd to jdk8-dev so that as many people as possible
know about it, but the discussion will be on the net-dev l
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
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
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,
t a blocking application will just block until
the 100 continue is received, before being allowed to send the body.
An asynchronous application will just not be "called back" to get the body
until the 100 is received.
Thanks
Michael
-Chris.
On 08/08/12 00:09, Michael McMahon wrote:
Hi,
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
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
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
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
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
ed by the fact that the Iterable can only be used to
return one Iterator instance.
HttpConnectionCache.CachedConnection::
- I would expect this to be abstract and that client providers would
extend.
- getCache() to return the client provider.
On Aug 7 2012, at 16:09 , Michael McMahon wrote:
- 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
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
hat the Iterable can only be used to
return one Iterator instance.
HttpConnectionCache.CachedConnection::
- I would expect this to be abstract and that client providers would extend.
- getCache() to return the client provider.
On Aug 7 2012, at 16:09 , Michael McMahon wrote:
Hi,
A new rev
redundant if no compatibility concerns. I was wondering maybe it is
>> OK to detach the HostnameVerifier interface and remove the verify() method.
>>
>> Maybe, you have other concerns that the HttpsConfigurator.verify()
>> method is really needed.
>>
>> Thanks,
>&
On 08/08/12 21:35, Chris Hegarty wrote:
Great suggestion Anthony,
This is something that comes up from time to time. With the clear
distinction between java.net.HttpURLConnection and
javax.net.ssl.HttpsURLConnection API's then it was a little difficult
to do in the existing API, but there is
was wondering maybe it is
OK to detach the HostnameVerifier interface and remove the verify() method.
Maybe, you have other concerns that the HttpsConfigurator.verify()
method is really needed.
Thanks,
Xuelei
On 8/8/2012 7:09 AM, Michael McMahon wrote:
Hi,
A new revision of the Http client A
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http client API [1] for
JDK 8.
This message has been cc'd to jdk8-dev so that as many people as possible
know about it, but the discussion will be on the net-dev list
(net-dev@openjdk.java.net)
Hi,
We have just published a draft of a proposed new Http client API [1] for
JDK 8.
This message has been bcc'd to jdk8-dev so that as many people as possible
know about it, but the discussion will be on the net-dev list
(net-dev@openjdk.java.net).
So, folks will have to join that li
.
Thanks again,
Michael.
On 08/08/12 00:09, 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
/proxy/etc
10) Missing fluent style return from HttpRequest.setRequestBodyLimit
11) Should sendHeaders be specified to allow a null return value. I'm
thinking about when setSendExpectContinue is set.
-Chris.
On 08/08/12 00:09, Michael McMahon wrote:
Hi,
A new revision of the Http c
lear?
- getBodyAsByteBufferSource -- if the same iterator is always returned why not
return the iterator rather than an iterable?
HttpConnectionCache.CachedConnection::
- I would expect this to be abstract and that client providers would extend.
- getCache() to return the client provider.
On Aug
el.x.mcma...@oracle.com>>> 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/
<http://cr.openjdk.java.net/~__michae
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
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
ntent type
> parser, or one programming model, over another.
>
> Does this make sense? Have I missed the point of your proposal? Maybe
> others have a different view...
>
> -Chris.
>
>
>>
>>
>> On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon
>>
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
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.
ys returned why not
return the iterator rather than an iterable?
HttpConnectionCache.CachedConnection::
- I would expect this to be abstract and that client providers would extend.
- getCache() to return the client provider.
On Aug 7 2012, at 16:09 , Michael McMahon wrote:
>
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
://javafx-jira.kenai.com/browse/RT-21275 ). The solution
to this JavaFX issue says the fix "enhanced code to follow https
redirects." So JavaFX seems to already implement this feature.
Thanks for your feedback
Anthony Vanelverdinghe
Op 8/08/2012 1:09, Michael McMahon schreef:
Hi,
A n
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
1:09, Michael McMahon schreef:
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.
Thanks
Michael McMahon.
ove the verify() method.
Maybe, you have other concerns that the HttpsConfigurator.verify()
method is really needed.
Thanks,
Xuelei
On 8/8/2012 7:09 AM, Michael McMahon wrote:
> Hi,
>
> A new revision of the Http client API planned for jdk 8 can be viewed
> at the following link
>
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
missed the point of your proposal? Maybe
others have a different view...
-Chris.
On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon
mailto:michael.x.mcma...@oracle.com>> wrote:
Hi,
A new revision of the Http client API planned for jdk 8 can be viewed
at the followin
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
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.
Thanks
Michael McMahon.
79 matches
Mail list logo
