Re: Why are com.sun.net.HttpExchange attributes shared between instances?

[Michael McMahon]

Hi,

I think I agree that the spec is not completely clear on this point. 
While it doesn't explicitly say
that attributes are per-exchange, it does kind of imply that. My 
preference would be to tighten
up the spec; make clear what is normative (the current behavior) and 
distinguish from that

what is informative, (the example of how filters could use the mechanism).

Go ahead and file a bug and we can take it from there.

Thanks

Michael.

On 10/12/2019 11:10, Julien Royer wrote:

Hi,

I’m having some troubles understanding how com.sun.net.HttpExchange 
attributes (setAttribute and getAttribute methods) work. Looking at 
the Javadoc, I understood that these attributes were specific to a 
given HttpExchange instance:



https://hg.openjdk.java.net/jdk/jdk/file/a4fb32538898/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java#l219
Filter modules may store arbitrary objects with HttpExchange
instances as an out-of-band communication mechanism.


This was also my intuition since these methods are defined on 
HttpExchange and HttpContext (similar 
to javax.servlet.ServletRequest#setAttribute 
and javax.servlet.ServletContext#setAttribute).


When using them on a project, I realised that my intuition was wrong 
though. The source code is very explicit:



https://hg.openjdk.java.net/jdk/jdk/file/a4fb32538898/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#l366
if (attributes == null) {
  attributes = getHttpContext().getAttributes();
}


Is the code wrong or is my understanding of the Javadoc incorrect? If 
so, shouldn’t it be clarified somehow?


Thank you,
Julien

P.S. this question was also asked on stackoverflow: 
https://stackoverflow.com/questions/59178977/are-com-sun-net-httpserver-httpexchange-attributes-broken

Re: Multi Part publisher for java.net.http.HttpClient

[Daniel Fuchs]

Hi Behrang,

net-dev is a better list to discuss networking/http related topics.


On 03/12/2019 12:22, Behrang Saeedzadeh wrote:> Hi all,
>
> Are there any plans to implement a "multipart/form-data" BodyPublisher in
> Java 14 or later?

There are no plans - especially not for 14 since we will be in
ramp down 1 this week, but I have logged JDK-8235761 [1] to do
some investigation.

best regards,

-- daniel

[1] https://bugs.openjdk.java.net/browse/JDK-8235761

Re: [PATCH] 7006496: Use modern Windows API to retrieve OS DNS servers

[Aleks Efimov]

Hi Anuraag,

The webrev with the latest patch can be viewed here:
http://cr.openjdk.java.net/~aefimov/anuraaga/7006496/02

Thanks for replacing FirstDnsSuffix usages with DnsSuffix. I've double 
checked it with native application and can confirm that on my test host 
(Microsoft Windows Server 2016 Standard) the DnsSuffix contains correct 
information while the FirstDnsSuffix list is empty:

    DNS Suffix (From DnsSuffix field):  test.domain.com
    Number of IP Adapter DNS suffix entries: 0

    DNS Suffix (From DnsSuffix field):
    Number of IP Adapter DNS suffix entries: 0

    DNS Suffix (From DnsSuffix field):
    Number of IP Adapter DNS suffix entries: 0

    DNS Suffix (From DnsSuffix field):
    Number of IP Adapter DNS suffix entries: 0

    DNS Suffix (From DnsSuffix field):  test.domain.com
    Number of IP Adapter DNS suffix entries: 0

About site-local addresses: Maybe we can move the site-local address 
check to native code? i.e. analyze dnsServer->Address.lpSockaddr and 
filter out site-local addresses.


Testing:
Run your latest patch though our CI system -  no issues detected.

-Aleksei

On 10/12/2019 06:59, Anuraag Agrawal wrote:

Hi Aleksei,

Thanks for running the test. I had checked the global search list, but 
realize I didn't check connection-specific suffixes which were causing 
the issue you see. While the documentation states that FirstDnsSuffix 
is populated on Vista+, amazingly it doesn't seem to be


https://docs.microsoft.com/en-us/windows/win32/api/iptypes/ns-iptypes-ip_adapter_addresses_lh 



Chromium has run into the same issue and just doesn't use the field

https://cs.chromium.org/chromium/src/net/dns/dns_config_service_win.cc?q=firstdnssuffix&sq=package:chromium&dr=C&l=532

So I have gone ahead and switched to using the normal DnsSuffix field. 
DnsSuffix and looking up the search list in the registry should 
generally give a full list.


During this testing, other issues I found are that the search list 
returns a comma-separated list. So to keep the string list parsing 
simple, I changed the delimiter from space to comma. Also, on my 
machine I would always have DNS servers like fec0:0:0::1 on some 
adapters. At first, I assumed it is ok to return these, since they are 
configured by the OS and should be valid, but I learnt that these are 
deprecated IPv6 site-local addresses and should not be used.


https://en.wikipedia.org/wiki/Unique_local_address

I used the same check for site-local as Inet6Address, which just sees 
if the first bytes are fec0.


Thanks again - inline patch follows.

diff --git 
a/src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java 
b/src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java

index 2250b3158e..b9a06461ab 100644
--- 
a/src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java
+++ 
b/src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java

@@ -25,9 +25,9 @@

 package sun.net.dns;

+import java.util.ArrayList;
 import java.util.List;
-import java.util.LinkedList;
-import java.util.StringTokenizer;
+import java.util.concurrent.TimeUnit;

 /*
  * An implementation of sun.net.ResolverConfiguration for Windows.
@@ -50,30 +50,65 @@ public class ResolverConfigurationImpl

     // Cache timeout (120 seconds) - should be converted into property
     // or configured as preference in the future.
-    private static final int TIMEOUT = 12;
+    private static final long TIMEOUT_NANOS = 
TimeUnit.SECONDS.toNanos(120);


     // DNS suffix list and name servers populated by native method
     private static String os_searchlist;
     private static String os_nameservers;

     // Cached lists
-    private static LinkedList searchlist;
-    private static LinkedList nameservers;
-
-    // Parse string that consists of token delimited by space or commas
-    // and return LinkedHashMap
-    private LinkedList stringToList(String str) {
-        LinkedList ll = new LinkedList<>();
-
-        // comma and space are valid delimiters
-        StringTokenizer st = new StringTokenizer(str, ", ");
-        while (st.hasMoreTokens()) {
-            String s = st.nextToken();
-            if (!ll.contains(s)) {
-                ll.add(s);
+    private static ArrayList searchlist;
+    private static ArrayList nameservers;
+
+    // Parse string that consists of token delimited by comma
+    // and return ArrayList. Refer to ResolverConfigurationImpl.c and
+    // strappend to see how the string is created.
+    private ArrayList stringToList(String str) {
+        // String is delimited by comma.
+        String[] tokens = str.split(",");
+        ArrayList l = new ArrayList<>(tokens.length);
+        for (String s : tokens) {
+            if (!l.contains(s)) {
+                l.add(s);
             }
         }
-        return ll;
+        l.trimToSize();
+        return l;
+    }
+
+    // Parse string that consists of token delimited 

Re: [PATCH] 7006496: Use modern Windows API to retrieve OS DNS servers

[Anuraag Agrawal]

Hi Aleksei,

Thanks for the feedback. I had thought about it but felt that it might be
better to leave as much business logic to Java vs native as possible as a
general principle. But if it makes more sense to do it native here happy to
make the change :)

Thanks,
- Anuraag

On Thu, Dec 12, 2019, 01:18 Aleks Efimov  wrote:

> Hi Anuraag,
>
> The webrev with the latest patch can be viewed here:
> http://cr.openjdk.java.net/~aefimov/anuraaga/7006496/02
>
> Thanks for replacing FirstDnsSuffix usages with DnsSuffix. I've double
> checked it with native application and can confirm that on my test host
> (Microsoft Windows Server 2016 Standard) the DnsSuffix contains correct
> information while the FirstDnsSuffix list is empty:
> DNS Suffix (From DnsSuffix field):  test.domain.com
> Number of IP Adapter DNS suffix entries: 0
>
> DNS Suffix (From DnsSuffix field):
> Number of IP Adapter DNS suffix entries: 0
>
> DNS Suffix (From DnsSuffix field):
> Number of IP Adapter DNS suffix entries: 0
>
> DNS Suffix (From DnsSuffix field):
> Number of IP Adapter DNS suffix entries: 0
>
> DNS Suffix (From DnsSuffix field):  test.domain.com
> Number of IP Adapter DNS suffix entries: 0
>
> About site-local addresses: Maybe we can move the site-local address check
> to native code? i.e. analyze dnsServer->Address.lpSockaddr and filter out
> site-local addresses.
>
> Testing:
> Run your latest patch though our CI system -  no issues detected.
>
> -Aleksei
>
> On 10/12/2019 06:59, Anuraag Agrawal wrote:
>
> Hi Aleksei,
>
> Thanks for running the test. I had checked the global search list, but
> realize I didn't check connection-specific suffixes which were causing the
> issue you see. While the documentation states that FirstDnsSuffix is
> populated on Vista+, amazingly it doesn't seem to be
>
>
> https://docs.microsoft.com/en-us/windows/win32/api/iptypes/ns-iptypes-ip_adapter_addresses_lh
>
>
> Chromium has run into the same issue and just doesn't use the field
>
>
> https://cs.chromium.org/chromium/src/net/dns/dns_config_service_win.cc?q=firstdnssuffix&sq=package:chromium&dr=C&l=532
>
> So I have gone ahead and switched to using the normal DnsSuffix field.
> DnsSuffix and looking up the search list in the registry should generally
> give a full list.
>
> During this testing, other issues I found are that the search list returns
> a comma-separated list. So to keep the string list parsing simple, I
> changed the delimiter from space to comma. Also, on my machine I would
> always have DNS servers like fec0:0:0::1 on some adapters. At first, I
> assumed it is ok to return these, since they are configured by the OS and
> should be valid, but I learnt that these are deprecated IPv6 site-local
> addresses and should not be used.
>
> https://en.wikipedia.org/wiki/Unique_local_address
>
> I used the same check for site-local as Inet6Address, which just sees if
> the first bytes are fec0.
>
> Thanks again - inline patch follows.
>
> diff --git
> a/src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java
> b/src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java
> index 2250b3158e..b9a06461ab 100644
> ---
> a/src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java
> +++
> b/src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java
> @@ -25,9 +25,9 @@
>
>  package sun.net.dns;
>
> +import java.util.ArrayList;
>  import java.util.List;
> -import java.util.LinkedList;
> -import java.util.StringTokenizer;
> +import java.util.concurrent.TimeUnit;
>
>  /*
>   * An implementation of sun.net.ResolverConfiguration for Windows.
> @@ -50,30 +50,65 @@ public class ResolverConfigurationImpl
>
>  // Cache timeout (120 seconds) - should be converted into property
>  // or configured as preference in the future.
> -private static final int TIMEOUT = 12;
> +private static final long TIMEOUT_NANOS =
> TimeUnit.SECONDS.toNanos(120);
>
>  // DNS suffix list and name servers populated by native method
>  private static String os_searchlist;
>  private static String os_nameservers;
>
>  // Cached lists
> -private static LinkedList searchlist;
> -private static LinkedList nameservers;
> -
> -// Parse string that consists of token delimited by space or commas
> -// and return LinkedHashMap
> -private LinkedList stringToList(String str) {
> -LinkedList ll = new LinkedList<>();
> -
> -// comma and space are valid delimiters
> -StringTokenizer st = new StringTokenizer(str, ", ");
> -while (st.hasMoreTokens()) {
> -String s = st.nextToken();
> -if (!ll.contains(s)) {
> -ll.add(s);
> +private static ArrayList searchlist;
> +private static ArrayList nameservers;
> +
> +// Parse string that consists of token delimited by comma
> +// and return ArrayList. Refer to ResolverConfigur

Re: Why are com.sun.net.HttpExchange attributes shared between instances?

[Julien Royer]

Hi,

> On 11 Dec 2019, at 10:48, Michael McMahon  
> wrote:
> Go ahead and file a bug and we can take it from there.
> 
Thank you Michael.

> Bug Report Submission Complete
> Thank you for taking the time to provide us with your details.
> We will review your report and have assigned it an internal review ID : 
> 9063054.
> Thanks
> 
> Michael.
> 
> On 10/12/2019 11:10, Julien Royer wrote:
>> Hi,
>> 
>> I’m having some troubles understanding how com.sun.net.HttpExchange 
>> attributes (setAttribute and getAttribute methods) work. Looking at the 
>> Javadoc, I understood that these attributes were specific to a given 
>> HttpExchange instance:
>> 
>> https://hg.openjdk.java.net/jdk/jdk/file/a4fb32538898/src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java#l219
>>  
>> 
>> Filter modules may store arbitrary objects with HttpExchange instances as an 
>> out-of-band communication mechanism.
>> 
>> This was also my intuition since these methods are defined on HttpExchange 
>> and HttpContext (similar to javax.servlet.ServletRequest#setAttribute and 
>> javax.servlet.ServletContext#setAttribute).
>> 
>> When using them on a project, I realised that my intuition was wrong though. 
>> The source code is very explicit:
>> 
>> https://hg.openjdk.java.net/jdk/jdk/file/a4fb32538898/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#l366
>>  
>> 
>> if (attributes == null) {
>>   attributes = getHttpContext().getAttributes();
>> }
>> 
>> Is the code wrong or is my understanding of the Javadoc incorrect? If so, 
>> shouldn’t it be clarified somehow?
>> 
>> Thank you,
>> Julien
>> 
>> P.S. this question was also asked on stackoverflow: 
>> https://stackoverflow.com/questions/59178977/are-com-sun-net-httpserver-httpexchange-attributes-broken
>>  
>> 

Re: Why are com.sun.net.HttpExchange attributes shared between instances?

[Chris Hegarty]

> On 11 Dec 2019, at 17:35, Julien Royer  wrote:
> 
> Hi,
> 
>> On 11 Dec 2019, at 10:48, Michael McMahon  
>> wrote:
>> Go ahead and file a bug and we can take it from there.
>> 
> Thank you Michael.
> 
> > Bug Report Submission Complete
> > Thank you for taking the time to provide us with your details.
> > We will review your report and have assigned it an internal review ID : 
> > 9063054.

Publicly visible at:
https://bugs.openjdk.java.net/browse/JDK-8235786
-Chris.

Re: Is SPNEGO supposed to work out of the box on domain joined Windows client

[Daniel Fuchs]

Hi,

By default transparent authentication is disabled on windows.
You may have to specify a non-default value for the
jdk.http.ntlm.transparentAuth property [1], or configure
an Authenticator [2] that has the appropriate credentials.

[1] https://bugs.openjdk.java.net/browse/JDK-8225506
[2] 
https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/net/HttpURLConnection.html#setAuthenticator(java.net.Authenticator)


best regards,

-- daniel

On 10/12/19 21:11, Marcin Wiśnicki wrote:
Forgive me for asking possibly silly question but I looked everywhere 
and couldn't find a simple answer to this question:


If I use standard java.net  classes to establish 
connection to HTTP server that uses SPNEGO authentication (AD) from a 
Windows machine that's joined to AD, without further configuration, is 
this supposed to work?

Re: Is SPNEGO supposed to work out of the box on domain joined Windows client

[Weijun Wang]

> On Dec 12, 2019, at 8:23 AM, Daniel Fuchs  wrote:
> 
> Hi,
> 
> By default transparent authentication is disabled on windows.
> You may have to specify a non-default value for the
> jdk.http.ntlm.transparentAuth property [1], or configure
> an Authenticator [2] that has the appropriate credentials.

The above is for NTLM.

For the Negotiate scheme, it's almost out-of-box.

1. Java is able to find realm and KDC via environment variables
2. Java can use the LSA cache if a realm user is logged in

but you'll need a special registry key [1] set for #2 above.

Or you can bridge to a native GSS library, you need to set the system property 
sun.security.jgss.native to true. JDK 13 contains its own native GSS library 
but if you're still on JDK 11, you also need to point the system property 
sun.security.jgss.lib to a 3rd-party GSS library (Ex: from MIT).

--Max

[1] 
https://support.microsoft.com/en-us/help/2627903/access-to-session-keys-not-possible-using-a-restricted-token

> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8225506
> [2] 
> https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/net/HttpURLConnection.html#setAuthenticator(java.net.Authenticator)
> 
> best regards,
> 
> -- daniel
> 
> On 10/12/19 21:11, Marcin Wiśnicki wrote:
>> Forgive me for asking possibly silly question but I looked everywhere and 
>> couldn't find a simple answer to this question:
>> If I use standard java.net  classes to establish connection 
>> to HTTP server that uses SPNEGO authentication (AD) from a Windows machine 
>> that's joined to AD, without further configuration, is this supposed to work?
>