Thanks, Sean.
New webrev updated with your suggestions:
http://cr.openjdk.java.net/~juh/6500133/webrev.01/
Jason
On 08/15/2012 10:38 AM, Sean Mullan wrote:
This looks good to me. Couple of comments:
111: Can you add a comment, something like "Try parsing the URI again
after encoding/escaping
On 8/15/2012 3:26 AM, Xuelei Fan wrote:
More comments about whether we are able to override the default value.
On 8/15/2012 10:45 AM, Xuelei Fan wrote:
Thought more about the design, I would have to say that we cannot return
the default value in sslParameters.getServerNames(). Otherwise, the
Changeset: da14e2c90bcb
Author:robm
Date: 2012-08-15 22:46 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da14e2c90bcb
6931128: (spec) File attribute tests fail when run as root.
Reviewed-by: alanb
! src/share/classes/java/io/File.java
! test/java/io/File/Basic.java
! test/j
Changeset: 9d47f4850714
Author:jjh
Date: 2012-08-15 13:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714
7191449: update copyright year to match last edit in jdk8 langtools repository
Reviewed-by: jjh
Contributed-by: steve.si...@oracle.com
! make/jprt.prop
This looks good to me. Couple of comments:
111: Can you add a comment, something like "Try parsing the URI again
after encoding/escaping any illegal characters".
113-4: When this code was written there probably wasn't yet an
IOException(String, Throwable) ctor. Now there is, so you can change
On Aug 15, 2012, at 11:05 PM, Weijun Wang wrote:
>>>
4. I just noticed that the type can be also "sni-". What if someone
call setServerName("sni-0", "...")? Is it the same as calling
setServerName(SNI_HOST_NAME, "...")?
>>> Unspecified behavior. Maybe not, because of the val
4. I just noticed that the type can be also "sni-". What if someone
call setServerName("sni-0", "...")? Is it the same as calling
setServerName(SNI_HOST_NAME, "...")?
Unspecified behavior. Maybe not, because of the value encoding method.
We may throw exception in Oracle provider. Other provide
On 08/15/2012 10:34 PM, Xuelei Fan wrote:
On 8/15/2012 10:06 PM, Weijun Wang wrote:
Some suggestions to SSLParameters:
1. Since you now decide to exclude the default SNI value from
getServerNames(), maybe you can emphasis this by using "user-provided
server name" in the spec.
I have a parag
On 08/14/2012 10:45 PM, Xuelei Fan wrote:
I only reply on the items that I may need more review.
On 8/15/2012 7:54 AM, Brad Wetmore wrote:
SSLParameters.java
==
76: Not sure why you want/need a LinkedHashMap with only one currently
defined NameType. Even if there were multiple
On 8/15/2012 10:06 PM, Weijun Wang wrote:
> Some suggestions to SSLParameters:
>
> 1. Since you now decide to exclude the default SNI value from
> getServerNames(), maybe you can emphasis this by using "user-provided
> server name" in the spec.
>
I have a paragraph in setServerName:
* Note that
Some suggestions to SSLParameters:
1. Since you now decide to exclude the default SNI value from
getServerNames(), maybe you can emphasis this by using "user-provided
server name" in the spec.
2. At disableServerName(), maybe you can explicitly point out that "A
disabled server name type can
On 8/15/2012 9:36 PM, Xuelei Fan wrote:
> Updated webrev according to recent feedbacks:
> http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
> http://cr.openjdk.java.net./~xuelei/7068321/README_05.txt
>
> The major differences:
> 1. add constant SSLParameters.SNI_HOST_NAME, and sp
Updated webrev according to recent feedbacks:
http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
http://cr.openjdk.java.net./~xuelei/7068321/README_05.txt
The major differences:
1. add constant SSLParameters.SNI_HOST_NAME, and specify the format of
unknown SNI type (sni-) in Exten
Changeset: 35e024c6a62c
Author:andrew
Date: 2012-08-15 14:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35e024c6a62c
7110151: Use underlying platform's zlib library for Java zlib support
Summary: Make SYSTEM_ZLIB more flexible by using ZLIB_{CFLAGS,LIBS} and
building on
This paragraph was removed in the latest update. Please ignore the
webrev_spec.04 and previous webrevs, and review webrev_spec.05.
http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.05/
Thanks,
Xuelei
On 8/15/2012 3:24 PM, Bradford Wetmore wrote:
>
>
>>> How would the ServerHello be gener
Updated at
http://cr.openjdk.java.net/~weijun/7184246/webrev.01
Changes:
1. String values (even if there is only one) for the same key are stored
in a vector. Two methods are provided:
get(String... keys) returns the last value
getAll(String... keys) returns all values concatenate
More comments about whether we are able to override the default value.
On 8/15/2012 10:45 AM, Xuelei Fan wrote:
>>> >> Thought more about the design, I would have to say that we cannot return
>>> >> the default value in sslParameters.getServerNames(). Otherwise, the
>>> >> following two block of
How would the ServerHello be generated until you call this method and
then start the handshaking on the returned SSLSocket?
One can use SSLEngine.wrap()/unwrap() to generate handshaking messages
from socket I/O stream.
// accept a socket
// read/write the I/O with SSLEngine
// c
On 8/15/2012 2:10 PM, Bradford Wetmore wrote:
>
>
> On 8/14/2012 7:45 PM, Xuelei Fan wrote:
>
> 197: You're not planning to process (e.g.
> ServerHandshaker/ClientHandshaker.process_message) the consumed
> handshaking bytes immediately during the createSocket call, are
> you? Yo
19 matches
Mail list logo
