On Wed, 6 Jun 2018 at 21:03, Chris Hegarty wrote:
>
> > On 4 Jun 2018, at 03:48, James Roper wrote:
> >
> > ...
> >
> > +1 on variants of getContentType that give you either the media type or
> the charset parsed from the content type header. Without them, we're going
> to end up with a lot of r
Jaikiran,
> On 2 Jun 2018, at 07:22, Jaikiran Pai wrote:
>
> Hello,
>
> I've been experimenting with the new HttpClient API that's part of Java now.
> I am using the latest EA build 16 of Java 11 from here[1]. I'm still in the
> early stages of integrating this into one of the libraries where
> On 2 Jun 2018, at 07:29, Jaikiran Pai wrote:
>
> Hi,
>
> Attached is a trivial patch which fixes a typo in the javadoc of
> java.net.http.HttpClient class.
Thank you. Pushed: http://hg.openjdk.java.net/jdk/sandbox/rev/7b616fbd7d5b
-Chris.
> On 4 Jun 2018, at 03:48, James Roper wrote:
>
> ...
>
> +1 on variants of getContentType that give you either the media type or the
> charset parsed from the content type header. Without them, we're going to end
> up with a lot of regexps doing ad hoc parsing to get the information needed
> On 3 Jun 2018, at 12:07, Alan Bateman wrote:
>
> ...
> The following is the webrev to remove the detection of connection reset in
> the socket writing good. We can think of this as a follow-up to JDK-8199329
> in that it removes more of the JDK 1.4 era code that special cased connection
>
Resend with proper subject, doh.
-- Forwarded message --
From: Simone Bordet
Date: Wed, Jun 6, 2018 at 10:29 AM
Subject:
To: "net-dev@openjdk.java.net >> OpenJDK Network Dev list"
Hi,
we have stumbled upon the error below on Windows.
We suspect this is happening when closing
Hi,
we have stumbled upon the error below on Windows.
We suspect this is happening when closing sockets that have the linger
option set.
Since SocketDispatcher.close0() eventually calls the Windows API
closesocket(), this seems to be confirmed by this article:
https://msdn.microsoft.com/en-us/li
Hi all,
Finally to return to this topic. We have looked at a few different
approaches
and it seems the best way is to define a security property that can be set
in the java.security configuration file, but which can be overridden as a
system property. The current behavior will remain the defaul
