On 02/13/2014 07:33 AM, Florian Weimer wrote:
On 02/13/2014 02:21 PM, Alan Bateman wrote:
On 13/02/2014 12:54, Florian Weimer wrote:
Can we add further enumeration values to
java.net.StandardProtocolFamily? The spec does not say so, unlike
javax.lang.model.SourceVersion, and the code in the JD
On 09/25/2015 06:42 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote:
Here is the question to answer, which preference should be respected
firstly between cipher suite and application protocol? If application
protocol are preferred at first, of course, applicati
On 09/25/2015 07:29 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 2:15 PM, David M. Lloyd wrote:
...why does sorting even matter? Why should selection not be implemented
100% in user code, based on both the cipher suites list and application
protocol, rendering this whole discussion
Sorry I didn't get the reply from Simone Bordet - it must have gone to
only one of the two lists (which I'm not on).
On 9/25/2015 9:14 PM, Simone Bordet wrote:
I don't follow ?
SNI has APIs in JDK 8, you don't use SSLExplorer at all.
They're highly limited; you can only tell the socket/engine
On 09/25/2015 10:13 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd wrote:
Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine
to specify the selected protocol; this would be done during setup before you
initiate handshake (which is why you
On 09/25/2015 11:37 AM, Simone Bordet wrote:
David,
sorry, but I don't understand your proposal.
Can you please write it down in pseudo code what a server application
should do and what the JDK should do to negotiate HTTP/2 with a client
?
Sure.
A: receive raw SSL packet on Socket or SocketC
On 09/25/2015 12:13 PM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd wrote:
A: receive raw SSL packet on Socket or SocketChannel
A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info
This requires the application to write a TLS parser. This is
very low
risk to either the JDK/SE timeline or the EE timeline
* Since most or all of the "hard" logic is on the server side, the
majority of API consumers will have an easy time using the API
* We server developers can handle the rest!
On 09/25/2015 12:23 PM, David M. Lloyd wrote:
On
On 09/25/2015 02:11 PM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote:
The application protocol implementation chooses only valid cipher suites for
the protocol. Why would it choose one that is not valid, considering that
the protocol implementation itself is
Hi Brad, thanks for replying; comments are inline:
On 09/28/2015 08:40 PM, Bradford Wetmore wrote:
Several comments about David's proposal:
1. Only the initial ClientHellos are parsable.
===
The biggest problem I have with an Explorer-based design i
I didn't reply on this last week, but this looks workable to me. Thanks!
On 10/02/2015 07:19 PM, Bradford Wetmore wrote:
On 10/1/2015 7:35 PM, Xuelei Fan wrote:
On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
Major changes:
1. ApplicationProtocols is gone. The H2 black list and comparator
Hi,
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8134577/webrev/
which address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8134577
the operative word has been "eliminate".
As such, the interface and service descriptor
sun.net.spi.namese
I don't think this really makes sense as a place to ask these questions,
but I can probably answer them to an extent at least.
When a TCP connection is closed normally, the side (we'll call it A)
which initiates the close (usually by shutting down the write half of
the socket) sends a FIN and
On 10/04/2016 03:58 AM, Langer, Christoph wrote:
Hi,
I think I would also support replacing sun.net.ConnectionResetException with a
publicly available java.net.ConnectionResetException that subclasses
java.net.SocketException. But, as Chris mentions. a usage example would be
helpful.
At pre
The following statement:
URI uri = URI.create("local:");
fails with an exception like this:
java.lang.IllegalArgumentException: Expected scheme-specific part at
index 6: local:
at java.net.URI.create(URI.java:852)
at
org.jboss.ejb.client.Affinity$LocalAffinity.(Affinity.java:131)
On 12/05/2016 06:29 AM, Norman Maurer wrote:
Hi all,
I wonder if it would be possible to add a new public exception time for the
situation of an SocketChannel.accept(…) or SocketChannel.open(…) (and the same
for ServerSocket / Socket) failing because of too many open files.
The reason is beca
com>> wrote:
> Am 05.12.2016 um 18:48 schrieb David M. Lloyd :
>
>> On 12/05/2016 06:29 AM, Norman Maurer wrote:
>> Hi all,
>>
>> I wonder if it would be possible to add a new public exception time for
the situation of an Socke
8252996: Thread safety problem in java.net.ProxySelector
-
Commit messages:
- 8252996: Fix visibility issue in ProxySelector
Changes: https://git.openjdk.java.net/jdk/pull/184/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=184&range=00
Issue: https://bugs.openjdk.jav
On Thu, 17 Sep 2020 13:04:28 GMT, Daniel Fuchs wrote:
>> Seems like an oversight when proxy selector was added
>
> Hi David,
>
> I can sponsor this for you - unless you already have a sponsor?
>
> best regards,
> -- daniel
No, I do not (though @ChrisHegarty did take a peek at my original ML po
On Tue, 15 Sep 2020 13:54:14 GMT, David M. Lloyd
wrote:
> 8252996: Thread safety problem in java.net.ProxySelector
This pull request has now been integrated.
Changeset: cca3a26e
Author: David M. Lloyd
Committer: Daniel Fuchs
URL: https://git.openjdk.java.net/jdk/commit/cca3a
On 05/23/2008 10:20 AM, Jean-Christophe Collet wrote:
Hello,
I have posted an entry in my blog about the current status of the FTP
client API.
It contains a quick description of the project as well as a link to the
current draft of the API. So if you're interested in that topic go take
a look
On 05/23/2008 10:20 AM, Jean-Christophe Collet wrote:
Hello,
I have posted an entry in my blog about the current status of the FTP
client API.
[..]
As mentioned in the post, feedback is very strongly encouraged.
Some technical feedback:
1) FtpClient should implement java.io.Closeable in my
On 06/18/2008 11:03 AM, Christopher Hegarty - Sun Microsystems Ireland wrote:
I think that this thread should be moved to the net-dev alias.
I know that Michael is certainly a member of net-dev and is currently
the owner of the HTTP server.
OK, great. To restate the original subject of this
On 06/19/2008 05:11 AM, Michael McMahon wrote:
David,
It was originally intended that the httpserver API would be part of the
platform (actually in the package suggested above) but some members of
the umbrella JSR for jdk 6 didn't agree with including a http server API
in Java SE. So, it was dr
On 06/20/2008 06:30 AM, Michael McMahon wrote:
From a technical perspective, I'd really only make one change. Right
now, server contexts are registered on the HttpServer directly. It
would be nice if, instead of registering contexts, you just register a
HttpHandler directly on the HttpServer
On 08/20/2008 04:37 AM, Alan Bateman wrote:
Florian Weimer wrote:
:
I've been wondering for a while if it is possible (with reasonable
additional effort) to add new socket and socket address classes without
patching the JDK sources.
No, it's not. :-)
FWIW, a while back I prototyped an "in tre
On 08/26/2008 09:20 AM, Christopher Hegarty - Sun Microsystems Ireland wrote:
On 08/26/08 14:41, David M. Lloyd wrote:
On 08/20/2008 04:37 AM, Alan Bateman wrote:
FWIW, a while back I prototyped an "in tree" solution for
SocketChannel. The primary motive was to allow for Sock
On 08/26/2008 11:12 AM, Alan Bateman wrote:
David M. Lloyd wrote:
:
I just mean, what would be the benefit of using SocketAddress rather
than using a String or Path directly? You can avoid the difficulties
of extending SocketAddress by simply not using it.
If the protocol or socket address
On 08/27/2008 03:00 PM, Florian Weimer wrote:
* David M. Lloyd:
Doing this: UnixSocketChannel.open(String) or similar seems more
correct to me.
You need to do this twice, for SOCK_STREAM and SOCK_DGRAM.
If you go the route of using SocketChannel.open(SocketAddress), for
example, now you&#x
I've crafted a simple patch which extends the API of the embedded HTTP
server to support virtual hosts. The patch is designed to add the new
functionality without breaking existing implementations which do not
support virtual hosts, or code which uses the HttpServer API today. It
does not inc
handler)
Also, we need to think of the implications on HttpsServer.
Michael (cc'ed) is the author of this API. Maybe he has an opinion.
-Chris.
On 07/12/2009 11:23, Christopher Hegarty - Sun Microsystems Ireland wrote:
This is certainly interesting. Let me take a look and I'll get
opinion.
-Chris.
On 07/12/2009 11:23, Christopher Hegarty - Sun Microsystems Ireland
wrote:
This is certainly interesting. Let me take a look and I'll get back
to you later.
-Chris.
On 04/12/2009 20:17, David M. Lloyd wrote:
I've crafted a simple patch which extends the
On 12/14/2009 03:58 PM, Michael McMahon wrote:
The alternative is to select something O(1)-ish but this can
drastically limit what is possible. Though like I said, for my
purposes if you would allow for host name ("foo.bar.com") and a simple
pattern mechanism ("*.bar.com" but not, say, "foo.*.com
On 08/07/2012 06:09 PM, Michael McMahon wrote:
Hi,
A new revision of the Http client API planned for jdk 8 can be viewed
at the following link
http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/
We would like to review the api on this mailing list.
So, all comments are welcome.
Why not jav
On 04/11/2013 04:23 PM, mark.reinh...@oracle.com wrote:
Posted: http://openjdk.java.net/jeps/183
I have a few comments/random thoughts about this. It says:
Security: Will need to be reviewed carefully since this feature does relax the
network security model in two ways:
No explicit network
On 7/4/13 4:42 AM, Alan Bateman wrote:
On 04/07/2013 09:36, Bernd Eckenfels wrote:
Hello,
we see a possible handle/selector leak very similiar to this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118373
We see on linux unix domain sockets and on windows /dev/afd handles
which are
On 7/4/13 1:53 PM, Alan Bateman wrote:
On 04/07/2013 19:43, David M. Lloyd wrote:
XNIO uses Selectors (usually PollSelectorImpls) which are cached per
thread in order to mix blocking and non-blocking I/O. If you are
starting many short-lived threads and doing blocking operations on
XNIO
37 matches
Mail list logo
