I just would like to remind that session resumption is a very
important use case to support for ALPN.
Understood. The ALPN value is tied to a handshake, either already
completed and active (getApplicationProtocol()) or still in progress
(getHandshakeApplicationProtocol()). Each handshake r
298: This test is not actually calling into checkResult on the server side.
Ooops! You need to check the output of the wrap() before calling unwrap() as
it overwrites the serverResult. You need to put in a similar checkResult()
before doing the flip()s.
So checks are required before and
Thanks for the additional review comments.
Responses in-line below.
Updated webrev:
http://cr.openjdk.java.net/~vinnie/8144093/webrev.02/
> On 1 Dec 2015, at 01:32, Bradford Wetmore wrote:
>
>
> On 11/29/2015 4:08 PM, Vincent Ryan wrote:
>
> > Following on from Brad’s recent email, here is
Hello Sean,
An empty array is allowed: it means do not use ALPN.
I’ve updated the exception messages to display the offending length in each
case.
--- ALPNExtension.java Tue Dec 1 15:22:02 2015
+++ ALPNExtension.java Tue Dec 1 14:56:12 2015
@@ -97,11 +97,13 @@
listLength = s.get
It appears that there is an undocumented minimum timeout in the
IcmpSendEcho* functions. If the timeout parameter is set to a number
below this minimum timeout it is effectively ignored. Thus if you wanted
to ensure that you could ping a particular host within a certain timeout
less than the un
Hey Vinnie,
question on SSLParameters.setApplicationProtocols(String[] protocols) method
What happens if you pass an empty array into this method. Shouldn't it
throw an IllegalArgumentException ?
In ALPNExtension.java :
+if (listLength < 2 || listLength + 2 != len) {
+
Hi,
On Mon, Nov 30, 2015 at 1:08 AM, Vincent Ryan wrote:
> Hello,
>
> Following on from Brad’s recent email, here is the full webrev of the API
> and the implementation classes for ALPN:
> http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/
>
> In adds the implementation classes (sun/security
2015-12-01 17:53 GMT+09:00 Alan Bateman :
> This is JAX-WS so any changes to this code will probably need to go get
> pushed to the upstream project too. Best to send it to core-libs-dev (as the
> EE/JAX-* areas don't have their own mailing list here). Miroslav Kos is on
> that mailing list and is
On 01/12/2015 05:20, KUBOTA Yuji wrote:
Hi all,
Please review this issue and patch.
This is JAX-WS so any changes to this code will probably need to go get
pushed to the upstream project too. Best to send it to core-libs-dev (as
the EE/JAX-* areas don't have their own mailing list here). M
