Before I push the other change to HttpsURLConnection, I'd like
to make this change to stop the proliferation of binary testkeys files
in the test tree and make the SimpleSSLContext class more accessible.
http://cr.openjdk.java.net/~michaelm/8055747/webrev.01/
Thanks,
Michael
There doesn't seem to be any change to SocksProxy.java apart from the
copyright date.
Otherwise, the change looks fine. It just occurred to me that an update
to policytool
was made to know about the new NetworkPermission class. I don't think we
backported it to
8 even. But, for completeness sake
)
jdk/src/jdk.runtime/share/classes/sun/security/tools/policytool/PolicyTool.java
Will look into that as a follow up.
Actually, you are right. I was thinking about the update that was done
for URLPermission.
I need to file a bug for NetworkPermission.
Michael
regards,
Sean.
On 22/08/14 17:0
, Michael McMahon wrote:
This is the recently reported fix to HttpsURLConnection.equals
http://cr.openjdk.java.net/~michaelm/8055299/webrev.1/
The fix includes a test. Not shown in the webrev is java key store
file called testkeys, which is copied from another location
in the test tree and is to
ut I'm not sure if
jtreg provides a property, or other, to expose this.
I looked into it, and there's nothing usable in the environment
unfortunately. It's a pity TEST.ROOT isn't provided.
Thanks,
Michael
-Chris.
On 21/08/14 12:33, Michael McMahon wrote:
Bef
Thanks for doing this Max. The syntax looks fine.
Just one question. Do you think it is better to specify each socket
option literally in the tool
as you have done (ie. the only supported NetworkPermission
is SO_FLOW_SLA with this change) or allow users to type in the option
name as free-form t
On 26/08/14 09:05, Wang Weijun wrote:
On Aug 26, 2014, at 15:57, Michael McMahon wrote:
Thanks for doing this Max. The syntax looks fine.
Just one question. Do you think it is better to specify each socket option
literally in the tool
as you have done (ie. the only supported
Could I get the following small change reviewed please?
One file was missed from my earlier change to SimpleSSLContext
http://cr.openjdk.java.net/~michaelm/8056065/webrev.1/
Thanks,
Michael.
On 26/08/14 15:06, Alan Bateman wrote:
On 26/08/2014 15:01, Michael McMahon wrote:
Could I get the following small change reviewed please?
One file was missed from my earlier change to SimpleSSLContext
http://cr.openjdk.java.net/~michaelm/8056065/webrev.1/
This looks okay to me, I assume that
Looks fine to me
Michael
On 12/09/14 10:05, Chris Hegarty wrote:
On 11/09/14 14:42, Chris Hegarty wrote:
A small issue was found when running JCK tests on modern Windows
platforms, that have IPv6 enabled, but forced to run with the IPv4
Stack, -Djava.net.preferIPv4Stack=true.
NetworkInterfa
Hi Ivan,
Did you look at the possibility of removing the TwoStacks class altogether?
For Solaris/Linux etc. ipv4 only and ipv6/v4 are all handled in the same
impl class
with just a switch at socket creation time, selecting AF_INET or AF_INET6.
If there is a good reason to keep the implementati
t make sense to include the equivalent changes there also. There
might need to
be some code in net_util_md.c that needs to be removed also
(NET_Timeout2() function?)
Thanks
Michael
On 23/09/14 11:49, Ivan Gerasimov wrote:
Thanks Michael!
On 23.09.2014 13:41, Michael McMahon wrote:
Hi Ivan,
Did
On 24/09/14 08:50, Alan Bateman wrote:
On 24/09/2014 02:19, Martin Sawicki (MS OPEN TECH) wrote:
Hello
We’re proposing an improvement to the OpenJDK which enables users to
take advantage of the TCP loopback fast path mechanism in Windows for
significantly higher performance of sockets whose
On 24/09/14 10:43, Michael McMahon wrote:
On 24/09/14 08:50, Alan Bateman wrote:
On 24/09/2014 02:19, Martin Sawicki (MS OPEN TECH) wrote:
Hello
We’re proposing an improvement to the OpenJDK which enables users to
take advantage of the TCP loopback fast path mechanism in Windows
for
On 30/09/14 17:41, Mark Sheppard wrote:
thanks Chris ... so shall we go with the simplest thing that works :-)
i.e. somehost.some-domain ?
Maybe include a few random characters in the top-level domain.
The list of TLDs has expanded so much in recent years, you never
know what might happen
Mi
Hi Volker,
I agree on the refactoring proposal. That would be a useful thing to do.
On the second point. Removing getnameinfo() and using AI_CANONNAME in
getaddrinfo() instead, would not be the exact equivalent however.
getnameinfo() with AI_CANONNAME is taking the canonical host name as
reporte
same implementation for all platforms.
Michael
On 10/10/14 15:03, Michael McMahon wrote:
Hi Volker,
I agree on the refactoring proposal. That would be a useful thing to do.
On the second point. Removing getnameinfo() and using AI_CANONNAME in
getaddrinfo() instead, would not be the exact equivalent ho
http://cr.openjdk.java.net/~michaelm/8042622/webrev.1/
The issue is that ResponseCache is receiving all the headers from our
MessageHeader internal implementation class. This includes
a dummy/fake header that represents the request line of a request
(eg GET /foo.html HTTP/1.1) and this is causing
Could I get the following small change reviewed please?
http://cr.openjdk.java.net/~michaelm/8062744/webrev.1/
In JDK 9 the problem only affects the Socket.supportedOptions() method,
but the same change is needed in 8 to allow the IP_TOS option to be set
in a ServerSocket.
Thanks
Michael
On 04/11/14 10:51, Alan Bateman wrote:
On 04/11/2014 10:44, Michael McMahon wrote:
Could I get the following small change reviewed please?
http://cr.openjdk.java.net/~michaelm/8062744/webrev.1/
In JDK 9 the problem only affects the Socket.supportedOptions() method,
but the same change is
On 04/11/14 11:10, Alan Bateman wrote:
On 04/11/2014 11:00, Michael McMahon wrote:
Thanks Alan. How about I just split the test and check the option
setting behavior in OptionsTest.java
which doesn't have any reference to the jdk.net.Sockets APIs and then
check the Sockets.supportedOp
On 04/11/14 11:18, Chris Hegarty wrote:
On 4 Nov 2014, at 11:15, Michael McMahon wrote:
On 04/11/14 11:10, Alan Bateman wrote:
On 04/11/2014 11:00, Michael McMahon wrote:
Thanks Alan. How about I just split the test and check the option setting
behavior in OptionsTest.java
which doesn&#
On 04/11/14 12:49, Chris Hegarty wrote:
On 4 Nov 2014, at 12:05, Michael McMahon wrote:
On 04/11/14 11:18, Chris Hegarty wrote:
On 4 Nov 2014, at 11:15, Michael McMahon wrote:
On 04/11/14 11:10, Alan Bateman wrote:
On 04/11/2014 11:00, Michael McMahon wrote:
Thanks Alan. How about I
On 04/11/14 14:45, Michael McMahon wrote:
On 04/11/14 12:49, Chris Hegarty wrote:
On 4 Nov 2014, at 12:05, Michael McMahon
wrote:
On 04/11/14 11:18, Chris Hegarty wrote:
On 4 Nov 2014, at 11:15, Michael McMahon
wrote:
On 04/11/14 11:10, Alan Bateman wrote:
On 04/11/2014 11:00, Michael
Chris
This looks fine to me.
Thanks
Michael
On 07/11/14 11:44, Chris Hegarty wrote:
This is a trivial change to fix a failed previous attempt to prevent
all HTTP requests, with a streaming body, from automatically being
retried, by the HttpURLConnection implementation.
The existing implemen
Hi Wenbo,
We are just doing some prototyping at the moment, and hope to have an API
proposal for discussion early in the new year.
Thanks,
Michael
On 18/12/14 02:42, Wenbo Zhu wrote:
I am new to the JEP process. Has there been any update on this work?
Is there an API proposal to look at?
Tha
Hi,
I'm afraid you have the wrong Michael McMahon.
-Original Message-
From: Konstantin Shefov
Sent: Monday, December 15, 2014 6:16 AM
To: Ivan Gerasimov; net-dev@openjdk.java.net; core-libs-...@openjdk.java.net;
Alan Bateman; Chris Hegarty; MICHAEL.MCMAHON
Subject: Re: [9] R
Hi,
JEP 110 HTTP 2 client
in JDK 9, is defining and implementing a new API for HTTP which also
supports
the new HTTP version 2 that has recently been working its way through
the IETF.
The work also includes support for websockets (RFC 6455).
In fact, the majority of the API is agnostic about
;The response body can then be received (either
synchronously or asynchronously)."
* HttpRequest: "Path body = r2.body(asFile("/tmp/response.txt));"
should be "Path body = r2.body(asFile("/tmp/response.txt"));"
* HttpRequest: "All of above examples&qu
On 20/04/15 18:32, Severin Gehwolf wrote:
On Mon, 2015-04-20 at 12:24 -0400, Andrew Hughes wrote:
- Original Message -
Adding in net-dev.
On Mon, 2015-04-20 at 14:02 +0200, Severin Gehwolf wrote:
Hi,
Could I please get a review and a sponsor for the following patch?
The issue is tha
On 21/04/15 14:56, Alan Bateman wrote:
On 20/04/2015 18:32, Severin Gehwolf wrote:
:
OK fixed:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.02/
FWIW, I don't think the test needs IP addresses of DNS servers to be
functional, though. All it really does is passing it to
InetAd
Rob,
There are a few more places where the same limited doPrivileged call occurs
in HttpURLConnection and which need the same change.
Michael
On 20/05/15 13:24, Rob McKenna wrote:
Hi folks,
Looking for a review of this webrev:
http://cr.openjdk.java.net/~robm/8077155/webrev.01/
Basically th
Looks good.
Michael.
On 20/05/15 13:59, Rob McKenna wrote:
Gah, sorry, should have paid more attention to the original change:
http://cr.openjdk.java.net/~robm/8077155/webrev.02/
-Rob
On 20/05/15 13:34, Michael McMahon wrote:
Rob,
There are a few more places where the same limited
Sounds like a native configuration issue all right. The native
connect appears to be getting an EPERM which according to Linux manpage
could be caused b a local firewall rule
Michael
On 01/06/15 21:14, Bobby Bissett wrote:
Hi all,
Can someone tell me how to diagnose this issue? I can't create
Seems reasonable Rob. I guess a test isn't feasible?
Michael.
On 03/06/15 14:25, Rob McKenna wrote:
Hi folks,
7180557 used getifaddrs as a way of determining the local hosts ip
address on Mac OSX in order to fix a problem with OSX's naming system.
When fixing this we decided to place that ca
8 schrieb Bobby Bissett <mailto:bbiss...@gmail.com>>:
Whoo-hoo! With these two bits of info and some time with my network
guru, I can finally connect. Info below:
On Tue, Jun 2, 2015 at 5:09 AM, Michael McMahon
mailto:michael.x.mcma...@oracle.com>>
wrote:
Sounds like a
Sean,
I'm happy with this change now.
Thanks
Michael
On 25/05/15 15:01, Seán Coffey wrote:
Jumping back on this issue...Michael identified a regression on linux
with my last webrev. It was connected with IPv6 sockets connecting to
IPv4 interfaces. Linux seems to cater for IP_TOS settings in
On 12/06/15 10:05, Seán Coffey wrote:
Michael,
I'd like to backport this fix to JDK 8u60. The port is pretty much the
same as 9 except for modular path changes. The OptionsTest modified in
jdk9 fix does not exist in jdk8u (test was for new API in JDK 9)
As a result, I was able to modify the
, 2015 at 9:27 AM, Michael McMahon
mailto:michael.x.mcma...@oracle.com>>
wrote:
Hi,
JEP 110 HTTP 2 client
in JDK 9, is defining and implementing a new API for HTTP which
also supports
the new HTTP version 2 that has recently been working its way
through th
Thanks for the quick review, Simone.
Some answers below.
Michael
On 31/07/15 14:10, Simone Bordet wrote:
Hi,
On Fri, Jul 31, 2015 at 9:00 AM, Michael McMahon
wrote:
Hi Wenbo,
The latest version of the docs is available at:
http://cr.openjdk.java.net/~michaelm/8087112/2/
I am hoping to
On 31/07/15 14:56, Michael McMahon wrote:
T
== HttpRequest.create(URI) and related.
Using a URI is not correct since requests may be made for targets that
are not URIs, see https://tools.ietf.org/html/rfc7230#section-5.3.
Examples: OPTIONS * HTTP/1.1, CONNECT foo:9090 HTTP/1.1 where "*
On 31/07/15 16:06, Simone Bordet wrote:
Hi,
On Fri, Jul 31, 2015 at 3:56 PM, Michael McMahon
wrote:
Ok. Now, on the whole flow-control issue, here is my thinking.
First that isFast() method is a relic from a previous version and should not
have been there.
My thinking is that the body
Wenbo,
On WebSockets, that API work is being handled separately to this work
and will be put out for review very soon.
- Michael
On 31/07/15 19:37, Wenbo Zhu wrote:
On Fri, Jul 31, 2015 at 11:32 AM, Simone Bordet
mailto:simone.bor...@gmail.com>> wrote:
Hi,
On Fri, Jul 31, 2015 a
at 6:33 PM, Michael McMahon
wrote:
Well, it needs co-operation between the producer and the consumer
obviously. But, the onResponseBodyChunk() method could write to a queue
and block if it reaches a certain size. The onRequestBodyChunk() would
read off the data and send it on. When the queue reach
ould then be reasonable in the async case, where the
CF
completes before the CF of the request, indicating a likely error. It's
probably a minority
use-case, but I think it's good for the API not to preclude it.
- Michael.
On 01/08/15 10:23, Michael McMahon wrote:
Here is what I
Looks reasonable to me Rob.
Thanks
Michael
On 11/08/15 19:08, Rob McKenna wrote:
Hi folks,
Upon investigating what turned out to be a network traffic filtering
problem it was noticed that Windows InetAddress.isReachable()
leverages TCP to detect other hosts on the network. Since new APIs for
Hi,
I'm looking for reviewers for the http client implementation.
This is just the common API layer and the http/1.1 implementation.
The webrev is at http://cr.openjdk.java.net/~michaelm/8087112/01/
Below is a description of the API classes and the relationship with
their implementation classes
On 02/09/15 21:17, Andrej Golovnin wrote:
Hi Pavel,
- Where's the .ping() or .pong() ?
* @apiNote Keep-alive features of WebSocket protocol are taken care of
* completely by implementations and are not exposed in this API.
We thought that a high-level API could live without this burden for th
On 03/09/15 09:28, Andrej Golovnin wrote:
Hi Michael,
Can you explain why you need j.n.Proxy rather than the
String/InetSocketAddress
combination proposed for HttpClient?
String is not type safe. And allowing to define proxy only for the
specific protocol is not enough from my experience. Some
On 08/09/15 17:29, Simone Bordet wrote:
Where is TLS support ? Let's not make the same mistake already done in
javax.websocket :) Thanks !
I notice it doesn't say so explicitly but "wss" urls are supported, and
the relevant configuration
comes from the HttpClient that the WebSocket belongs t
On 27/09/15 18:19, Simone Bordet wrote:
Hi,
On Fri, Aug 28, 2015 at 10:50 PM, Michael McMahon
wrote:
Hi,
I'm looking for reviewers for the http client implementation.
This is just the common API layer and the http/1.1 implementation.
The webrev is at http://cr.openjdk.java.net/~mic
On 28/09/15 10:13, Simone Bordet wrote:
Hi,
On Mon, Sep 28, 2015 at 10:45 AM, Michael McMahon
wrote:
The API has already been approved and the first version to
be integrated won't have all suggestions incorporated.
But, it should be possible to address many of them in time
for JDK 9 a
On 28/09/15 11:23, Simone Bordet wrote:
Hi,
On Mon, Sep 28, 2015 at 11:38 AM, Michael McMahon
wrote:
if the units are ByteBuffers say, then how do you convert a notification
of n units into a HTTP/2 window update (which has to be in bytes)?
The implementation always has this information
Anthony,
Thanks for the feedback. I am currently looking at API issues
but will incorporate these changes when I get back to the implementation.
- Michael
On 27/09/15 09:14, Anthony Vanelverdinghe wrote:
Hi Michael
I forgot to mention that, in Utils.java [1], the exception should also
be thr
Looks fine to me Rob
- Michael
On 25/09/15 13:54, Rob McKenna wrote:
Good point. I'll remove that pre-push.
-Rob
On 25/09/15 11:57, Mark Sheppard wrote:
Hi Rob,
looks fine ... the "him" variable in the
Java_java_net_Inet4AddressImpl_isReachable0
would appear not to be used now, s
Hi,
A new revision of the API can be seen at:
http://cr.openjdk.java.net/~michaelm/8087112/04/
The main changes are:
- package name change. Moved to own package java.net.httpclient
- proxy setting uses ProxySelector (a static factory method will be added
to ProxySelector for setting a simpl
On 30/09/15 17:34, Michael McMahon wrote:
Hi,
A new revision of the API can be seen at:
http://cr.openjdk.java.net/~michaelm/8087112/04/
The main changes are:
- package name change. Moved to own package java.net.httpclient
- proxy setting uses ProxySelector (a static factory method will be
Hi,
I think this is a reasonable observation. We actually changed
ProxySelector itself to provide (one) simple factory method for
a fixed Proxy using an InetSocketAddress for all requests and that
makes setting a simple proxy very easy.
But, I agree it probably makes more sense for the default b
On 22/10/15 14:24, Alan Bateman wrote:
On 22/10/2015 14:04, Roger Riggs wrote:
Hi Sandhya,
The folks on net-dev@openjdk.java.net will be interested too.
Yes, net-dev is the best list for this.
One other thing to mention is the SocketOption interface and the
setOption/getOption methods. Thi
Hi Kishor
Did you mean to include the patch with this message?
If you send it, I can convert it to a webrev and put
it on the cr.openjdk server for review
Thanks
Michael
On 16/11/15 18:49, Kharbas, Kishor wrote:
Hello all,
I request the community to review a patch for adding SO_REUSEPORT
su
dk.java.net/~mcberg/jdk/6432031/webrev.01/
I presume that a review is requested for this patch?
regards
Mark
On 19/11/2015 14:11, Michael McMahon wrote:
Hi Kishor
Did you mean to include the patch with this message?
If you send it, I can convert it to a webrev and put
it on the cr.openjdk server
gqi Lu (Lucy)
*From:*net-dev [mailto:net-dev-boun...@openjdk.java.net] *On Behalf Of
*Michael McMahon
*Sent:* Thursday, November 19, 2015 6:11 AM
*To:* Kharbas, Kishor; net-dev@openjdk.java.net
*Subject:* Re: Patch for adding SO_REUSEPORT socket option
Hi Kishor
Did you mean to include the patch wit
same port, must have set the option.
*/
On 23/11/15 10:54, Michael McMahon wrote:
I agree we should enable the option on all platforms.
We can add the code to do that and run the tests.
On the existing use of SO_REUSEPORT on AIX and Mac
it appears that is set to emulate expected behavior on
I agree we should enable the option on all platforms.
We can add the code to do that and run the tests.
On the existing use of SO_REUSEPORT on AIX and Mac
it appears that is set to emulate expected behavior on
other platforms when SO_REUSEADDR is set for datagram sockets.
The expectation is that
ve all the OSes so that I might not be able to test them.
Can any of you please help with the testing?
Alan, I will add the isReusePortSupported method in the Net.c and only add
SO_REUSEPORT into the options set only when it is supported.
Thank you,
Lucy
-Original Message-----
From: Micha
25, 2015 12:17 PM
*To:* Lu, Yingqi mailto:yingqi...@intel.com>>
*Cc:* Michael McMahon <mailto:michael.x.mcma...@oracle.com>>; Alan Bateman
mailto:alan.bate...@oracle.com>>; Kharbas,
Kishor mailto:kishor.khar...@intel.com>>;
net-dev@openjdk.java.net <mailto:net-d
Yes, since the functionality is basically duplicated across the two
mechanisms
and since setOption/getOption already exists, the only new part of the API
is the SO_REUSEPORT option itself in StandardSocketOptions.
- Michael
On 07/12/15 17:04, Lu, Yingqi wrote:
Hi Alan and Michael,
Thank you
Hi Artem,
On 04/12/15 11:41, Artem Smotrakov wrote:
Hello,
Please review this small fix for DigestAuthentication class.
1. Added a check in DigestAuthentication.setNonce(String) that nonce
is not null. NPE may happen if a buggy HTTP server returns
"WWW-Authenticate" header which doesn't con
617
...
qop-options = "qop" "=" <"> 1#qop-value <">
qop-value = "auth" | "auth-int" | token
...
Please take a look at updated webrev:
http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.01/
Artem
On 12/2
Artem,
The change looks fine.
Thanks,
Michael
On 04/01/16 18:39, Artem Smotrakov wrote:
Hi Michael,
On 01/04/2016 02:28 AM, Michael McMahon wrote:
On 30/12/15 03:22, Artem Smotrakov wrote:
Hi Michael,
Thanks for review, it looks like BNF notation uses only a comma as a
separator
http
Hi,
The following webrevs are for the initial implementation of JEP 110.
Most of it is in the jdk repository with some build configuration in the top
level repo for putting this code in its own module (java.httpclient).
http://cr.openjdk.java.net/~michaelm/8087112/01/top/webrev/
http://cr.openj
Hi Paul
Thanks for the review. Some comments below
On 17/02/16 15:26, Paul Sandoz wrote:
On 4 Feb 2016, at 17:14, Michael McMahon
mailto:michael.x.mcma...@oracle.com>>
wrote:
Hi,
The following webrevs are for the initial implementation of JEP 110.
Most of it is in the jdk repo
On 18/02/16 16:06, Paul Sandoz wrote:
On 18 Feb 2016, at 16:37, Michael McMahon wrote:
When building a request how does one set multiple values for a header?
setHeaders overwrites, does one used headers(…) instead?
headers(String, String)
and headers(String ...) both accumulate headers
BuilderImpl: 96; should copy() be doing a deep copy of the
User Headers?
Otherwise, subsequent changes to either HttpRequestBuilder would
affect the other.
RedirectFilter: 85: Invalid redirection exception should include the
invalid value for debug.
That's it for now,
Roger
On
= HttpServer.create(new
InetSocketAddress(8080), 0);
server.setExecutor(null);
server.createContext("/", e -> {
e.getRequestBody().readAllBytes();
server.stop(0);
});
server.start();
}
}
import java.io.IOException;
import java.net.
On 04/03/16 16:05, Daniel Fuchs wrote:
Please find below a patch for:
https://bugs.openjdk.java.net/browse/JDK-8151281
8151281: Module java.httpclient could use System.Logger
instead of PlatformLogger
http://cr.openjdk.java.net/~dfuchs/webrev_8151281/webrev.00/
best regards,
-- danie
Could I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/8151299/webrev.1/
Thanks,
Michael.
On 08/03/16 12:15, Claes Redestad wrote:
Hi Michael,
On 2016-03-08 12:27, Michael McMahon wrote:
Could I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/8151299/webrev.1/
get on LinkedList is O(n), so the for-loop in resetInterestOps
sneakily has quadratic
This is a small change, where an internal completion result
was getting lost.
http://cr.openjdk.java.net/~michaelm/8151441/webrev.1/
Thanks
Michael
On 08/03/16 14:10, Claes Redestad wrote:
On 2016-03-08 14:42, Michael McMahon wrote:
Iterator-based removal would work, or building a new list to replace
pending with might be more efficient. The synchronization scheme
seems a bit flaky as well?
The new code is always called from the
On 09/03/16 10:24, Michael McMahon wrote:
On 08/03/16 14:10, Claes Redestad wrote:
Another oddity in the surrounding code is that
System.currentTimeMillis() is always called, but only used when
selector.select(timeval) == 0 - could this be moved into the if-block?
266 long now
being a nested class of a nested class.
And also that is holds a reference to this. So I changed this in my comments
webrev.
-Chris.
On 8 Mar 2016, at 11:27, Michael McMahon wrote:
Could I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/8151299/webrev.1/
Thanks
Looks good Naoto.
- Michael.
On 21/03/16 15:19, Naoto Sato wrote:
Pinging. Can anyone please review this simple fix?
Naoto
On 3/18/16 10:53 AM, Naoto Sato wrote:
Hello,
Please review the fix to the following bug:
https://bugs.openjdk.java.net/browse/JDK-8060097
The proposed fix is located
Hi,
This is the webrev for the HTTP/2 part of JEP 110.
http://cr.openjdk.java.net/~michaelm/8087124/webrev.1/index.html
There are minor changes to existing classes as well as the bulk
of the new stuff in the new files. Most of the HTTP/2 implementation
is in the files:
|| src/java.httpclient/s
2016/4/6 22:08, Michael McMahon wrote:
Hi,
This is the webrev for the HTTP/2 part of JEP 110.
http://cr.openjdk.java.net/~michaelm/8087124/webrev.1/index.html
There are minor changes to existing classes as well as the bulk
of the new stuff in the new files. Most of the HTTP/2 implementation
is i
On 07/04/16 11:20, Simone Bordet wrote:
Michael,
On Wed, Apr 6, 2016 at 4:08 PM, Michael McMahon
wrote:
Hi,
This is the webrev for the HTTP/2 part of JEP 110.
http://cr.openjdk.java.net/~michaelm/8087124/webrev.1/index.html
Can I ask how you guys apply webrevs to the JDK 9 source tree ?
I
On 07/04/16 11:28, Simone Bordet wrote:
Hi,
On Thu, Apr 7, 2016 at 12:22 PM, Michael McMahon
wrote:
Simone,
The webrev should include a patch file that you can apply to
the source tree. The link is at the top of the page (jdk.patch)
Tried that with
patch -p1 < jdk.patch
I get a lot
On 07/04/16 14:19, Simone Bordet wrote:
Hi,
On Wed, Apr 6, 2016 at 4:08 PM, Michael McMahon
wrote:
Hi,
This is the webrev for the HTTP/2 part of JEP 110.
http://cr.openjdk.java.net/~michaelm/8087124/webrev.1/index.html
Before I dive further into this, seems to me that the implementation
On 07/04/16 14:37, Simone Bordet wrote:
Hi,
On Thu, Apr 7, 2016 at 3:27 PM, Michael McMahon
wrote:
At the lowest level the implementation uses two threads per TCP connection,
one for reading and one for writing.
Ugh.
I do plan to change that to dispatch from
the selector
and execute the
Hi,
ALPN is set in the HttpConnection class.
Checking the exact ciphers selected is not implemented
yet. That will come later. I am currently updating the implementation to
get rid of the
two threads per connection limitation and will have a new webrev then.
So I will address other review comm
a non-blocking version of SSLDelegate).
Thanks
Michael
On 06/04/16 15:08, Michael McMahon wrote:
Hi,
This is the webrev for the HTTP/2 part of JEP 110.
http://cr.openjdk.java.net/~michaelm/8087124/webrev.1/index.html
There are minor changes to existing classes as well as the bulk
of the new
s,
Michael.
On 27/04/16 11:41, Chris Hegarty wrote:
On 22 Apr 2016, at 22:51, Michael McMahon wrote:
Hi,
An updated webrev is available at:
http://cr.openjdk.java.net/~michaelm/8087124/webrev.2/
The main change is the removal of the permanently allocated
two threads per TCP connection (
Some tests with hardcoded port numbers were included in the initial http
tests.
The fix uses a driver to allocate a free port and pass it into the existing
security test through a system property.
http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html
Thanks,
Michael
n 5/3/2016 7:44 AM, Michael McMahon wrote:
Some tests with hardcoded port numbers were included in the initial
http tests.
The fix uses a driver to allocate a free port and pass it into the
existing
security test through a system property.
http://cr.openjdk.java.net/~michaelm/8155928/web
te it themselves ( i understand that this will be more work, and possibly
require some refactoring ).
-Chris.
On 4 May 2016, at 17:06, Michael McMahon wrote:
Hi Roger,
Thanks for the review. That permission is not actually required for the
test. But, it did make me look closer at it,
r
On 5/3/2016 7:44 AM, Michael McMahon wrote:
Some tests with hardcoded port numbers were included in the initial http tests.
The fix uses a driver to allocate a free port and pass it into the existing
security test through a system property.
http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/
Another occasional test case failure. It's a concurrent modification
exception caused
by modifying a list during processing of the list (by the same thread).
The solution
is to keep separate lists of the modifications and to process them after
the iterator
completes.
http://cr.openjdk.java.net
Simple change to set default use of TLSv1.2 when the user
has not specified which protocols to use.
http://cr.openjdk.java.net/~michaelm/8153572/webrev.1/
The change is in HttpClientImpl.java but also includes some logging
additions.
Thanks
Michael
I'd prefer to hold off with this change Felix. I recently pushed
a change to that test which removes the hardcoded port numbers
and also fixes another problem with the test.
- Michael.
On 10/05/16 04:17, Felix Yang wrote:
Hi there,
please review the following patch to mark
java/net/httpc
This test is still failing intermittently. The reason is that one of the
places where BindException
can be thrown is called by reflection. So, the exception is wrapped in
an InvocationTargetException
and needs to be unwrapped.
http://cr.openjdk.java.net/~michaelm/8156801/webrev.1/
Thanks,
Mich
101 - 200 of 1041 matches
Mail list logo
