Hi,
On Mon, Apr 18, 2016 at 10:09 PM, Michael McMahon
wrote:
> Hi,
>
> ALPN is set in the HttpConnection class.
>
> Checking the exact ciphers selected is not implemented
> yet. That will come later.
I am guessing checking for the actual application protocol too ?
Sending "h2" via ALPN does not
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
On 18/04/16 15:30, Pavel Rappo wrote:
On 13 Apr 2016, at 10:10, Chris Hegarty wrote:
A general comment; Quite a number of classes, especially Encoder and Decoder,
would benefit from a few relatively lightweight comments, e.g. IntegerReader
I would like to address it after the initial push.
Thanks for the quick review Chris,
I'll push as soon as JPRT runs look green.
/Claes
On 04/18/2016 04:45 PM, Chris Hegarty wrote:
Looks ok Claes.
-Chris.
On 18/04/16 15:38, Claes Redestad wrote:
Hi,
a small omission in JDK-8154238 cause Windows builds to fail. Sorry
about that, see patch t
Looks ok Claes.
-Chris.
On 18/04/16 15:38, Claes Redestad wrote:
Hi,
a small omission in JDK-8154238 cause Windows builds to fail. Sorry
about that, see patch to fix this below (I was 100% certain I had run this
through JPRT last week)
Bug: https://bugs.openjdk.java.net/browse/JDK-8154454
Th
Hi,
a small omission in JDK-8154238 cause Windows builds to fail. Sorry
about that, see patch to fix this below (I was 100% certain I had run this
through JPRT last week)
Bug: https://bugs.openjdk.java.net/browse/JDK-8154454
Thanks!
/Claes
diff -r 3459ee432728
src/java.base/windows/classes
> On 13 Apr 2016, at 10:10, Chris Hegarty wrote:
>
> A general comment; Quite a number of classes, especially Encoder and Decoder,
> would benefit from a few relatively lightweight comments, e.g. IntegerReader
I would like to address it after the initial push. If possible. Other than that,
I ha
Hi,
is there any plan to make the new HTTP/2 and WebSocket client
implementation replaceable via a ServiceLoader mechanism ?
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performanc
Hi,
I am missing where the ALPN negotiation is performed in the new HTTP/2
client code, can you direct me at where this is done ?
The HTTP/2 spec requires to close the connection with
INADEQUATE_SECURITY if the cipher does not meet the HTTP/2
requirements, but I don't see this code ?
SSLEngine.g
On 18/04/16 11:09, Claes Redestad wrote:
On 04/18/2016 12:06 PM, Chris Hegarty wrote:
On 18/04/16 11:01, Alan Bateman wrote:
On 18/04/2016 10:45, Chris Hegarty wrote:
The changes look fine.
Maybe the bug description should be updated a before pushing,
it looks like it affects only legacy net
On 04/18/2016 12:06 PM, Chris Hegarty wrote:
On 18/04/16 11:01, Alan Bateman wrote:
On 18/04/2016 10:45, Chris Hegarty wrote:
The changes look fine.
Maybe the bug description should be updated a before pushing,
it looks like it affects only legacy networking code and not
NIO. Maybe "... and a
On 18/04/16 11:01, Alan Bateman wrote:
On 18/04/2016 10:45, Chris Hegarty wrote:
The changes look fine.
Maybe the bug description should be updated a before pushing,
it looks like it affects only legacy networking code and not
NIO. Maybe "... and async channels" ?
The changes to the NIO code
On 04/18/2016 12:01 PM, Alan Bateman wrote:
On 18/04/2016 10:45, Chris Hegarty wrote:
The changes look fine.
Maybe the bug description should be updated a before pushing,
it looks like it affects only legacy networking code and not
NIO. Maybe "... and async channels" ?
The changes to the NIO c
On 04/18/2016 11:45 AM, Chris Hegarty wrote:
On 14/04/16 13:49, Claes Redestad wrote:
Hi,
more code in the Windows socket implementation that can be dropped
Bug: https://bugs.openjdk.java.net/browse/JDK-8154238
Webrev: http://cr.openjdk.java.net/~redestad/8154238/webrev.01/
The changes look
On 18/04/2016 10:45, Chris Hegarty wrote:
The changes look fine.
Maybe the bug description should be updated a before pushing,
it looks like it affects only legacy networking code and not
NIO. Maybe "... and async channels" ?
The changes to the NIO code look okay but probably should be split in
On 14/04/16 13:49, Claes Redestad wrote:
Hi,
more code in the Windows socket implementation that can be dropped
Bug: https://bugs.openjdk.java.net/browse/JDK-8154238
Webrev: http://cr.openjdk.java.net/~redestad/8154238/webrev.01/
The changes look fine.
Maybe the bug description should be upd
On 12/04/16 21:27, Bernd Eckenfels wrote:
Hello,
a while back I brought up the discussion that there is no
preferIPV6=system (or similar) setting which allows to turn off the
reordering of address families by Java. Because only the OS can try to
correctly do target address determinaton.
A Bug
17 matches
Mail list logo
