mit/cd9a3cf05b2c200709103e2e8596414a62a1c441
Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with
"SocketException: Unexpected end of file from server"
Reviewed-by: dfuchs
-
PR: https://git.openjdk
pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains three additional
> commits since the last revision:
>
> - remove sun/net/www/protocol/http
On Wed, 16 Feb 2022 21:10:41 GMT, Daniel Fuchs wrote:
> A seemingly innocuous change from
> [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a
> test failure. The fix is to simply revert that small change.
This pull request has been closed without being integrated.
On Thu, 17 Feb 2022 17:13:38 GMT, Mahendra Chhipa wrote:
> Updated TunnelProxy to avoid twice read of Request line.
tier 2 mach5 Job :
https://mach5.us.oracle.com/mdash/jobs/mahendrachhipa-jdk-20220217-1608-29227569
-
PR: https://git.openjdk.java.net/jdk/pull/7519
On Thu, 17 Feb 2022 17:13:38 GMT, Mahendra Chhipa wrote:
> Updated TunnelProxy to avoid twice read of Request line.
Looks good to me Mahendra. I will withdraw my own PR. Just make sure to run the
whole of tier2 :-)
-
Marked as reviewed by dfuchs (Reviewer).
PR: https://git.openjd
Updated TunnelProxy to avoid twice read of Request line.
-
Commit messages:
- JDK-8282017 : sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
Changes: https://git.openjdk.java.net/jdk/pull/7519/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7519&
al webrev excludes the unrelated changes brought in
by the merge/rebase. The pull request contains three additional commits since
the last revision:
- remove sun/net/www/protocol/https/HttpsURLConnection/B6216082.java from
ProblemList
- Merge branch 'master' into B6216082
- 8
On Wed, 16 Feb 2022 21:27:40 GMT, Daniel Fuchs wrote:
> Please find here a changeset to ProblemList
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017
> is fixed
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7505
On Wed, 16 Feb 2022 21:27:40 GMT, Daniel Fuchs wrote:
> Please find here a changeset to ProblemList
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017
> is fixed
This pull request has now been integrated.
Changeset: 48f6e930
Author:Daniel F
On Wed, 16 Feb 2022 21:27:40 GMT, Daniel Fuchs wrote:
> Please find here a changeset to ProblemList
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017
> is fixed
LGTM
-
Marked as reviewed by michaelm (Reviewer).
PR: https://git.openjdk.jav
Please find here a changeset to ProblemList
sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017
is fixed
-
Commit messages:
- ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
until JDK-8282017 is fixed
Changes: https
A seemingly innocuous change from
[JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a
test failure. The fix is to simply revert that small change.
-
Commit messages:
- 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails
with
On Wed, 16 Feb 2022 21:10:41 GMT, Daniel Fuchs wrote:
> A seemingly innocuous change from
> [JDK-8061729](https://bugs.openjdk.java.net/browse/JDK-8061729) is causing a
> test failure. The fix is to simply revert that small change.
I am currently running tier2 tests in the CI
-
On Tue, 16 Feb 2021 07:50:05 GMT, Vyom Tewari wrote:
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
>if (s instan
On Thu, 4 Mar 2021 05:16:02 GMT, Xue-Lei Andrew Fan wrote:
>> Vyom Tewari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added a comment that host has bees set previously
>
> Thank you. I have no more comment.
Shouldn't there be a regr
On Thu, 4 Mar 2021 04:02:03 GMT, Vyom Tewari wrote:
>> HttpsURLConnection, works with SunJSSE provider but does not work with other
>> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
>> follows
>>
>> s = (SSLSocket)serverSocket;
>&g
On Thu, 4 Mar 2021 00:27:52 GMT, Xue-Lei Andrew Fan wrote:
>> Vyom Tewari has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - resolve jcheck issue.
>> - put if block which will prevent host being set twice in case of
>> SSLSocketImpl
>
>
;> -- daniel
>
>> Vyom, can you provide, or point to a test that exercises the code paths that
>> have been changed? And also some new test that would fail before the fix and
>> pass after?
>>
>> best regards,
>>
>> -- daniel
>
> Hi Danie
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
>if (s instanceof SSLSocketImpl) {
> ((SSLSocke
On Wed, 3 Mar 2021 17:56:02 GMT, Vyom Tewari wrote:
>> HttpsURLConnection, works with SunJSSE provider but does not work with other
>> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
>> follows
>>
>> s = (SSLSocket)serverSocket;
>&g
On Wed, 3 Mar 2021 16:16:48 GMT, Xue-Lei Andrew Fan wrote:
>> Vyom Tewari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reverted the overly deleted else block
>
> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
>if (s instanceof SSLSocketImpl) {
> ((SSLSocke
On Wed, 3 Mar 2021 15:10:54 GMT, Vyom Tewari wrote:
>> HttpsURLConnection, works with SunJSSE provider but does not work with other
>> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
>> follows
>>
>> s = (SSLSocket)serverSocket;
>&g
,
there are multiple test in
"test/jdk/sun/net/www/protocol/https/HttpsURLConnection" which exercises the
code paths that have been changed. To be more specific if you change the JSSE
provider for example to "BouncyCastle" then these test will fail because host
will not set for
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
>if (s instanceof SSLSocketImpl) {
> ((SSLSocke
On Wed, 3 Mar 2021 11:36:19 GMT, Vyom Tewari wrote:
>> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line
>> 454:
>>
>>> 452: s = (SSLSocket)factory.createSocket(serverSocket,
>>> 453: host, po
On Wed, 3 Mar 2021 10:05:24 GMT, Daniel Fuchs wrote:
>> Vyom Tewari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> used List.of instead of Collections.singletonList
>
> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.
On Wed, 3 Mar 2021 04:27:15 GMT, Vyom Tewari wrote:
>> HttpsURLConnection, works with SunJSSE provider but does not work with other
>> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
>> follows
>>
>> s = (SSLSocket)serverSocket;
>&g
On Wed, 3 Mar 2021 08:51:13 GMT, Vyom Tewari wrote:
>>> > HttpsURLConnection, works with SunJSSE provider but does not work with
>>> > other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host
>>> > name as follows
>>> > s =
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
>if (s instanceof SSLSocketImpl) {
> ((SSLSocke
On Wed, 3 Mar 2021 05:01:13 GMT, Vyom Tewari wrote:
>>> HttpsURLConnection, works with SunJSSE provider but does not work with
>>> other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host
>>> name as follows
>>>
>>> s =
On Wed, 3 Mar 2021 04:38:47 GMT, Xue-Lei Andrew Fan wrote:
> > HttpsURLConnection, works with SunJSSE provider but does not work with
> > other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host
> > name as follows
> > s = (SSLSocket)serverSock
On Tue, 16 Feb 2021 07:50:05 GMT, Vyom Tewari wrote:
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
> if (s instan
On Tue, 2 Mar 2021 20:17:25 GMT, Xue-Lei Andrew Fan wrote:
>> Vyom Tewari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> used List.of instead of Collections.singletonList
>
> src/java.base/share/classes/sun/net/www/protocol/https/HttpsC
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
>if (s instanceof SSLSocketImpl) {
> ((SSLSocke
On Tue, 16 Feb 2021 07:50:05 GMT, Vyom Tewari wrote:
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
>if (s instan
On Tue, 2 Mar 2021 15:56:35 GMT, Daniel Fuchs wrote:
>> i ran tests, it looks
>> clean(https://github.com/vyommani/jdk/actions/runs/612949667)
>
> As far as I know this is only tier1 - so none of the network tests have been
> run.
I ran tier1 & tier2 tests locally on my linux vm, it was clear.
On Tue, 2 Mar 2021 15:34:56 GMT, Vyom Tewari wrote:
>> Did you try to run the httpclient tests? They make use of the httpserver -
>> so they can also serve to test it - somewhat.
>> More generally - please run jdk_net/tier2 tests.
>
> i ran tests, it looks
> clean(https://github.com/vyommani/jd
On Tue, 2 Mar 2021 15:03:47 GMT, Daniel Fuchs wrote:
>> May be i am not sure, we may need this code change to review by security
>> expert. I am setting "SNIHostName" only if "isDefaultHostnameVerifier" is
>> true(If the HNV is the default from HttpsURL
t;> that this will introduce regressions in such cases?
>
> May be i am not sure, we may need this code change to review by security
> expert. I am setting "SNIHostName" only if "isDefaultHostnameVerifier" is
> true(If the HNV is the default from HttpsURLConnecti
On Tue, 2 Mar 2021 12:43:27 GMT, Daniel Fuchs wrote:
>> HttpsURLConnection, works with SunJSSE provider but does not work with other
>> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
>> follows
>>
>> s = (SSLSocket)server
On Tue, 16 Feb 2021 07:50:05 GMT, Vyom Tewari wrote:
> HttpsURLConnection, works with SunJSSE provider but does not work with other
> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
> follows
>
> s = (SSLSocket)serverSocket;
>if (s instan
HttpsURLConnection, works with SunJSSE provider but does not work with other
JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as
follows
s = (SSLSocket)serverSocket;
if (s instanceof SSLSocketImpl) {
((SSLSocketImpl)s).setHost(host);
}
But in case of
: RFR 8238579: HttpsURLConnection drops the timeout and hangs forever in readDate: Wed, Feb 26, 2020 7:40 PM
Hi Vyom,I tried out your patch and got no suspicious failures soyou have my review :-)best regards,-- danielOn 15/02/2020 04:14, Vyom Tewari26 wrote:> I'll get back to you when I have
-dev@openjdk.java.net, vyomm...@gmail.comSubject: [EXTERNAL] Re: RFR 8238579: HttpsURLConnection drops the timeout and hangs forever in readDate: Wed, Feb 26, 2020 7:40 PM
Hi Vyom,I tried out your patch and got no suspicious failures soyou have my review :-)best regards,-- danielOn 15/02/2020 04:14
Hi Vyom,
I tried out your patch and got no suspicious failures so
you have my review :-)
best regards,
-- daniel
On 15/02/2020 04:14, Vyom Tewari26 wrote:
I'll get back to you when I have managed to find some
cycles to do so.
best regards,
-- daniel
On 14/02/2020 04:57, Vyom Tiwari wrote:
Sounds good
Thanks,
Vyom
- Original message -From: Daniel Fuchs Sent by: "net-dev" To: Vyom Tiwari , net-dev , core-libs-dev Cc:Subject: [EXTERNAL] Re: RFR 8238579: HttpsURLConnection drops the timeout and hangs forever in readDate: Sat, Feb 15, 2020 1:11 AM
Hi Vyom,On the sur
Hi Vyom,
On the surface, your patch seems reasonable.
I would be more confident if there was a test, but I understand
it might well be one of these noreg-hard issues.
I've put it on my TODO list to import your patch and
try to test it in our test system.
I'll get back to you when I have managed
resolved.
Thanks,
Vyom
- Original message -From: "felixxfyang(杨晓峰)" Sent by: "core-libs-dev" To: Vyom Tiwari , net-dev , core-libs-dev Cc:Subject: [EXTERNAL] Re: RFR 8238579: HttpsURLConnection drops the timeout and hangs forever in read(Internet mail)Date: Fri, Feb 14, 20
Hi All,
Please find the below fix which resolves the issue(
https://bugs.openjdk.java.net/browse/JDK-8238579).
"HttpURLConnection.writeRequests()" retry in case of any write failure,
during retry it creates new HttpsClient without connectTimeout &
readTimeout. Below fix sets the connect & read
+1,
Another finalizer gone!
On 11/12/19 12:57 PM, Daniel Fuchs wrote:
Looks good to me Michael.
Good riddance! :-)
best regards,
-- daniel
On 12/11/2019 16:45, Michael McMahon wrote:
Hi,
Could I get the following small change reviewed please?
8233958 complains about memory retention caus
Looks good to me Michael.
Good riddance! :-)
best regards,
-- daniel
On 12/11/2019 16:45, Michael McMahon wrote:
Hi,
Could I get the following small change reviewed please?
8233958 complains about memory retention caused by a finalizer which
does nothing, other than delay garbage collection
Hi,
Could I get the following small change reviewed please?
8233958 complains about memory retention caused by a finalizer which
does nothing, other than delay garbage collection of the associated objects.
The proposed change is to remove the dead code.
http://cr.openjdk.java.net/~michaelm/823
Thank you for reviewing, Vyom and Daniel.
Daniel, would you push the change for me?
Changeset: http://cr.openjdk.java.net/~jboes/webrevs/8209178/webrev.02/
Cheers,
Julia
On 25/09/2019 13:12, Daniel Fuchs wrote:
Hi,
On 24/09/2019 16:11, Julia Boes wrote:
Hi,
This fix addresses an issue in
Hi,
On 24/09/2019 16:11, Julia Boes wrote:
Hi,
This fix addresses an issue in HttpClient when retrying a POST request
over proxied HTTPS.
[...]
Bug: https://bugs.openjdk.java.net/browse/JDK-8209178
Webrev:
http://cr.openjdk.java.net/~jboes/webrevs/8209178/webrev.00/index.html
This look
Hi Julia,
Fix looks good to me, i tested the fix it worked for us.
Thanks,
Vyom
- Original message -From: Julia Boes Sent by: "net-dev" To: net-dev@openjdk.java.netCc:Subject: [EXTERNAL] RFR: 8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST r
Hi,
This fix addresses an issue in HttpClient when retrying a POST request
over proxied HTTPS. In this case, the request body is stored in a
PosterOutputStream poster, which is set to null in
sun/net/www/protocol/http/HttpURLConnection::sendCONNECTRequest after
the first request.
The fix ad
==
10. Even if I try this simple httpsurlconnection java program to print
content it takes more than 10 seconds on ARM not in intel. Not sure why
please help
HttpsClient.java
import java.net.MalformedURLException;
import
On 11/8/18 4:06 PM, Xuelei Fan wrote:
To make sure the SecureCacheResponse class work, two new tests are added
(DefaultCacheResponse for default implementation, DummyCacheResponse for
a test implementation):
http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/
I think you mean http://cr
To make sure the SecureCacheResponse class work, two new tests are added
(DefaultCacheResponse for default implementation, DummyCacheResponse for
a test implementation):
http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/
Thanks,
Xuelei
On 11/8/2018 7:03 AM, Sean Mullan wrote:
On 11/7/1
On 08/11/2018 15:03, Sean Mullan wrote:
Ah, I see. I am sure there is a good reason, but why doesn't it have an
implementation?
IIRC there was an implementation in the deploy code.
best regards,
-- daniel
On 11/7/18 7:22 PM, Xuelei Fan wrote:
On 11/7/2018 1:30 PM, Sean Mullan wrote:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/
I didn't see a test for SecureCacheResponse - is it possible?
JDK does not have the reference implementat
On 11/7/2018 1:30 PM, Sean Mullan wrote:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/
I didn't see a test for SecureCacheResponse - is it possible?
JDK does not have the reference implementation of SecureCacheResponse.
You could
o:xuelei@oracle.com>> wrote:
On 11/1/2018 11:24 AM, Sean Mullan wrote:
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An applic
> On 5 Nov 2018, at 18:52, Xuelei Fan wrote:
>
> Hi Chris and Sean,
>
> There are a few feedback for the CSR approval. I updated to use
> Optional for the returned value. For more details, please refer
> to:
> https://bugs.openjdk.java.net/browse/JDK-8213161
> http://cr.openjdk.java.net/
23:42, Xuelei Fan <mailto:xuelei@oracle.com>> wrote:
On 11/1/2018 11:24 AM, Sean Mullan wrote:
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the pu
1/2018 11:24 AM, Sean Mullan wrote:
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need
richer information for the under
wrote:
>>>> Hi,
>>>>
>>>> For the current HttpsURLConnection, there is not much security parameters
>>>> exposed in the public APIs. An application may need richer information
>>>> for the underlying TLS connections, for example the negotia
On 11/1/2018 11:24 AM, Sean Mullan wrote:
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need
richer information for the
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
I removed the deprecation parts in the update. Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.01/
And the CSR was updated accordingly.
https://bugs.openjdk.java.net/browse/JDK-8213161
Thanks,
Xuelei
On 11/1/2018 4:57 AM, Chris Hegarty wrote:
On 31 Oct 2018, a
> On 31 Oct 2018, at 20:03, Xuelei Fan wrote:
>> ...
> Yes. I had the same concern about the optional operation. However, I came
> to a different conclusion if I'm from viewpoint of these users that need to
> use this new operation.
>
> If an application have to use this new operation, for e
On 10/31/2018 8:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
negotiated TLS protocol version.
Please
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
negotiated TLS protocol version.
Please let me know if you have concerns to add a new
On 27 Dec 2016, at 06:24, John Jiang wrote:
>
> Hi,
> sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh failed with
> timeout.
> The client side could hang if the server goes to timeout before getting the
> client request, and the proxy also could be blocked.
&g
Hi,
sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh failed
with timeout.
The client side could hang if the server goes to timeout before getting
the client request, and the proxy also could be blocked.
This patch sets timeout for the server and the client and catches
Changeset: bf2a14ebb6e9
Author:chegar
Date: 2013-01-23 14:45 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf2a14ebb6e9
8006669:
sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
fails on mac
Reviewed-by: alanb
!
test/sun/security/ssl/sun
On 22/01/2013 15:04, Chris Hegarty wrote:
These tests started failing recently on some mac machines. They appear
to hang and timeout.
FAILED:
sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
FAILED:
sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection
These tests started failing recently on some mac machines. They appear
to hang and timeout.
FAILED:
sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
FAILED:
sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh
Webrev
Changeset: b7b33a3c9df0
Author:xuelei
Date: 2012-09-04 02:24 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7b33a3c9df0
7195733: TEST_BUG:
sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
failing
Reviewed-by: chegar, alanb, xuelei
Contributed
Looks good also...
Brad
On 1/23/2012 4:27 AM, Xuelei Fan wrote:
Remove the serviceabilty-dev.
Thanks for the quick code review.
Xuelei
On 1/23/2012 8:25 PM, Alan Bateman wrote:
On 23/01/2012 12:21, Xuelei Fan wrote:
Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/
In JDK 8,
Thanks for taking care of this Andrew.
-Chris.
On 23/01/2012 12:21, Xuelei Fan wrote:
Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/
In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm mode.
In agentvm mode, multiple threads may share the thread pool. SunJSSE
implem
Changeset: d383b5d128e3
Author:xuelei
Date: 2012-01-23 04:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d383b5d128e3
7132248:
sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java
failing
Reviewed-by: alanb
!
test/sun/security/ssl
Remove the serviceabilty-dev.
Thanks for the quick code review.
Xuelei
On 1/23/2012 8:25 PM, Alan Bateman wrote:
On 23/01/2012 12:21, Xuelei Fan wrote:
Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/
In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm
mode. In a
On 23/01/2012 12:21, Xuelei Fan wrote:
Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/
In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm
mode. In agentvm mode, multiple threads may share the thread pool.
SunJSSE implementation initialize the SSL/TLS context at t
Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/
In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm mode.
In agentvm mode, multiple threads may share the thread pool. SunJSSE
implementation initialize the SSL/TLS context at the first time the
context get loaded, a
-27 02:17 -0700
> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5
>
> 7084040: Clearup warning in HttpsURLConnection
> Reviewed-by: xuelei
> Contributed-by: nsebastian.sickelm...@gmx.de
>
> ! src/share/classes/javax/net/ssl/HttpsURLConnection.java
>
Changeset: e4729ad0d7b5
Author:xuelei
Date: 2011-08-27 02:17 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4729ad0d7b5
7084040: Clearup warning in HttpsURLConnection
Reviewed-by: xuelei
Contributed-by: nsebastian.sickelm...@gmx.de
! src/share/classes/javax/net/ssl
Changeset: ed61accf772e
Author:chegar
Date: 2010-04-15 16:37 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ed61accf772e
6943219:
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
fail in linux
Reviewed-by: andrew
!
test/sun/security
Changeset: 8a9ebdc27045
Author:chegar
Date: 2010-03-23 13:54 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8a9ebdc27045
6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all
its Sockets
6771432: createSocket() - smpatch fails using 1.6.0_10
Changeset: a96a1f0edeeb
Author:xuelei
Date: 2009-02-04 19:10 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a96a1f0edeeb
6782783: regtest HttpsURLConnection/B6216082.java throws
ClosedByInterruptException
Summary: make the test robust
Reviewed-by: weijun
!
test/sun
92 matches
Mail list logo
