hg: jdk8/tl/jdk: 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc()
Changeset: 1e89a13d9d8f Author:chegar Date: 2011-10-10 10:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e89a13d9d8f 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc() Reviewed-by: michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java
hg: jdk8/tl/jdk: 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface
Changeset: 2a36b8741363 Author:chegar Date: 2011-10-10 15:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a36b8741363 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Reviewed-by: mcimadamore ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java
Re: ntlm with ms exchange server not working since java 1.7
Max [to'ed],
Does this look familiar? Is it wrong for the server to be returning
WWW-Authenticate: Negotiate during NTLM handshake?
-Chris.
On 08/10/2011 14:41, Mario Ivankovits wrote:
Hi net-devs,
I hope you do not mind that I post to this list, but I hope I can
provide enough in-depth information about the problem to justify the
post here.
Accessing a “normal” ntlm protected resource – a simple index.html in an
protected directory on an IIS 7.5 server - the ntlm authentication works
fine.
However, trying to access the Microsoft Exchange 2010 webservice failes
with “401 Unauthorized”.
I used this few lines to debug the connection/authentication process
URL url = new URL(https://exchange/ews/Services.wsdl;);
byte[] buf = new byte[10240];
int read = url.openStream().read(buf);
System.err.println(new String(buf, 0, read));
This snipped works fine in java 1.6, but failes with an IOException
(http status 401) in java 1.7.
I found an interesting difference when accessing the “normal” web-page
and the exchange webservice.
When accessing the web-page, the server answers “WWW-Authenticate:
Negotiate” just after the first 401 response which triggers the
authentication process then. In contrast, when accessing the Exchange
webservice the “WWW-Authenticate: Negotiate” is sent during the
negotiation process too, which then triggers the inNegotiate flag in
sun.net.www.protocol.http.HttpURLConnection in getInputStream and let
the negotiation process fail.
If I hack the response values and change any subsequent Negotiate to
e.g. NegotiateXX, then the inNegotiate flag will not change and the
authentication process will finish and authentication finally works.
Here is the request/response cycle which fail then:
#1: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}
#2: {null: HTTP/1.1 401 Unauthorized}{Server:
Microsoft-IIS/7.5}{WWW-Authenticate: Negotiate}{WWW-Authenticate:
NTLM}{X-Powered-By: ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39
GMT}{Content-Length: 0}
#3: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}{Authorization:
NTLM MY_NTLM_DATA}
#4: {null: HTTP/1.1 401 Unauthorized}{Server:
Microsoft-IIS/7.5}{WWW-Authenticate: NTLM
SERVER_NTLM_DATA}{WWW-Authenticate: Negotiate}{X-Powered-By:
ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39 GMT}{Content-Length: 0}
Exception in thread main java.io.IOException: Server returned HTTP
response code: 401 for URL: https://exchange/ews/Services.wsdl
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1612)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at java.net.URL.openStream(URL.java:1035)
Does this make sense to you?
It seems to me the “inNegotiate” handling needs a review as it does not
work in all cases.
I hope my informations are of any help to fix this issue.
Ciao,
Mario
Re: ntlm with ms exchange server not working since java 1.7
During an NTLM handshake, I've never seen a server mentioning another scheme.
As seen in message #4, the NTLM header still contains data, so there should not
be WWW-Authenticate: Negotiate header.
That said, this is only my experience. I tried to find any words on this from
an RFC but failed.
-Max
On Oct 10, 2011, at 7:48 AM, Chris Hegarty chris.hega...@oracle.com wrote:
Max [to'ed],
Does this look familiar? Is it wrong for the server to be returning
WWW-Authenticate: Negotiate during NTLM handshake?
-Chris.
On 08/10/2011 14:41, Mario Ivankovits wrote:
Hi net-devs,
I hope you do not mind that I post to this list, but I hope I can
provide enough in-depth information about the problem to justify the
post here.
Accessing a “normal” ntlm protected resource – a simple index.html in an
protected directory on an IIS 7.5 server - the ntlm authentication works
fine.
However, trying to access the Microsoft Exchange 2010 webservice failes
with “401 Unauthorized”.
I used this few lines to debug the connection/authentication process
URL url = new URL(https://exchange/ews/Services.wsdl;);
byte[] buf = new byte[10240];
int read = url.openStream().read(buf);
System.err.println(new String(buf, 0, read));
This snipped works fine in java 1.6, but failes with an IOException
(http status 401) in java 1.7.
I found an interesting difference when accessing the “normal” web-page
and the exchange webservice.
When accessing the web-page, the server answers “WWW-Authenticate:
Negotiate” just after the first 401 response which triggers the
authentication process then. In contrast, when accessing the Exchange
webservice the “WWW-Authenticate: Negotiate” is sent during the
negotiation process too, which then triggers the inNegotiate flag in
sun.net.www.protocol.http.HttpURLConnection in getInputStream and let
the negotiation process fail.
If I hack the response values and change any subsequent Negotiate to
e.g. NegotiateXX, then the inNegotiate flag will not change and the
authentication process will finish and authentication finally works.
Here is the request/response cycle which fail then:
#1: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}
#2: {null: HTTP/1.1 401 Unauthorized}{Server:
Microsoft-IIS/7.5}{WWW-Authenticate: Negotiate}{WWW-Authenticate:
NTLM}{X-Powered-By: ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39
GMT}{Content-Length: 0}
#3: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}{Authorization:
NTLM MY_NTLM_DATA}
#4: {null: HTTP/1.1 401 Unauthorized}{Server:
Microsoft-IIS/7.5}{WWW-Authenticate: NTLM
SERVER_NTLM_DATA}{WWW-Authenticate: Negotiate}{X-Powered-By:
ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39 GMT}{Content-Length: 0}
Exception in thread main java.io.IOException: Server returned HTTP
response code: 401 for URL: https://exchange/ews/Services.wsdl
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1612)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at java.net.URL.openStream(URL.java:1035)
Does this make sense to you?
It seems to me the “inNegotiate” handling needs a review as it does not
work in all cases.
I hope my informations are of any help to fix this issue.
Ciao,
Mario
AW: ntlm with ms exchange server not working since java 1.7
Hi!
I too did a lot of research on the internet regarding this http header field
... and didn't find something which defines a correct behavior for the server
during the negotiation phase.
The two phases the NTLM requires is a Microsoft extension, covered in many
details, but not able to answer this special question.
Though, the first 401 response is definitely allowed to respond with multiple
www-authenticate values. Be it comma-separated or by sending the field multiple
times.
This can be found in [1] section 14.47 (something you experts are surely aware
of .. *trying not to step on some ones toes* ;-) )
Further in [2] you can read, that a client should pick the most secure method
it supports and start authentication then.
Well, not much of news till here.
Now my interpretation of the above: A client should pick the most secure
authentication it is able to serve for the server and try this method. On
failure, try the next method.
With this in mind, I setup an IIS site which allows Negotiate, NTLM, Digest and
Basic and tried to open an java.net.URL against it.
To my surprise Digest will be chosen first (this is documented in
sun.net.www.protocol.http.AuthenticationHeader, but wrong I think, shouldn't it
be read like this: negotiate - kerberos - ntlm - digest - basic) - also no
other method will be tried yet.
Said that, I think the correct solution to this case will be to capture the
already tried authentication methods until we don't know how to proceed.
Instead of passing dontUseNegotiate to the AuthenticationHeader, we will pass
in a Set of already tried authentication methods.
This also should make it possible to avoid the use of inNegotiate.
What do you think?
I think I am going to play a bit with this idea ... :-)
Ciao,
Mario
[1] http://www.ietf.org/rfc/rfc2616.txt
[2] http://msdn.microsoft.com/en-us/library/aa479391.aspx
-Ursprüngliche Nachricht-
Von: Weijun Wang [mailto:weijun.w...@oracle.com]
Gesendet: Montag, 10. Oktober 2011 17:33
An: Chris Hegarty
Cc: Mario Ivankovits; net-dev@openjdk.java.net
Betreff: Re: ntlm with ms exchange server not working since java 1.7
During an NTLM handshake, I've never seen a server mentioning another scheme.
As seen in message #4, the NTLM header still contains data, so there should not
be WWW-Authenticate: Negotiate header.
That said, this is only my experience. I tried to find any words on this from
an RFC but failed.
-Max
On Oct 10, 2011, at 7:48 AM, Chris Hegarty chris.hega...@oracle.com wrote:
Max [to'ed],
Does this look familiar? Is it wrong for the server to be returning
WWW-Authenticate: Negotiate during NTLM handshake?
-Chris.
On 08/10/2011 14:41, Mario Ivankovits wrote:
Hi net-devs,
I hope you do not mind that I post to this list, but I hope I can
provide enough in-depth information about the problem to justify the
post here.
Accessing a “normal” ntlm protected resource – a simple index.html in
an protected directory on an IIS 7.5 server - the ntlm authentication
works fine.
However, trying to access the Microsoft Exchange 2010 webservice
failes with “401 Unauthorized”.
I used this few lines to debug the connection/authentication process
URL url = new URL(https://exchange/ews/Services.wsdl;);
byte[] buf = new byte[10240];
int read = url.openStream().read(buf);
System.err.println(new String(buf, 0, read));
This snipped works fine in java 1.6, but failes with an IOException
(http status 401) in java 1.7.
I found an interesting difference when accessing the “normal”
web-page and the exchange webservice.
When accessing the web-page, the server answers “WWW-Authenticate:
Negotiate” just after the first 401 response which triggers the
authentication process then. In contrast, when accessing the Exchange
webservice the “WWW-Authenticate: Negotiate” is sent during the
negotiation process too, which then triggers the inNegotiate flag in
sun.net.www.protocol.http.HttpURLConnection in getInputStream and let
the negotiation process fail.
If I hack the response values and change any subsequent Negotiate to
e.g. NegotiateXX, then the inNegotiate flag will not change and the
authentication process will finish and authentication finally works.
Here is the request/response cycle which fail then:
#1: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}
#2: {null: HTTP/1.1 401 Unauthorized}{Server:
Microsoft-IIS/7.5}{WWW-Authenticate: Negotiate}{WWW-Authenticate:
NTLM}{X-Powered-By: ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39
GMT}{Content-Length: 0}
#3: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}{Authorization:
NTLM MY_NTLM_DATA}
#4: {null: HTTP/1.1 401 Unauthorized}{Server:
Re: AW: ntlm with ms exchange server not working since java 1.7
On 10/10/2011 11:35 AM, Mario Ivankovits wrote: Hi! I too did a lot of research on the internet regarding this http header field ... and didn't find something which defines a correct behavior for the server during the negotiation phase. The two phases the NTLM requires is a Microsoft extension, covered in many details, but not able to answer this special question. Though, the first 401 response is definitely allowed to respond with multiple www-authenticate values. Be it comma-separated or by sending the field multiple times. This can be found in [1] section 14.47 (something you experts are surely aware of .. *trying not to step on some ones toes* ;-) ) Further in [2] you can read, that a client should pick the most secure method it supports and start authentication then. Well, not much of news till here. Now my interpretation of the above: A client should pick the most secure authentication it is able to serve for the server and try this method. On failure, try the next method. With this in mind, I setup an IIS site which allows Negotiate, NTLM, Digest and Basic and tried to open an java.net.URL against it. To my surprise Digest will be chosen first (this is documented in sun.net.www.protocol.http.AuthenticationHeader, but wrong I think, shouldn't it be read like this: negotiate - kerberos - ntlm - digest - basic) - also no other method will be tried yet. This is not a surprise. In order for Negotiate to happen, you need some Kerberos settings and without them it will not go very long. If I remember correctly, Digest is preferred to NTLM so it's the natural fallback. Said that, I think the correct solution to this case will be to capture the already tried authentication methods until we don't know how to proceed. That seems to be the only approach. But I still hope it is a server configuration error. Instead of passing dontUseNegotiate to the AuthenticationHeader, we will pass in a Set of already tried authentication methods. I'm not sure of that. The code logic here is quite fragile and it has underdone several rounds of update and tweaking, and I surely don't like to see anything broken. A rather ugly hack is to choose NTLM as long as it has extra parameter(s). Hopefully that's safe. We know NTLM has defined 3 messages and that means the final answer from server is simply 200 OK without any 4th confirmation... -Max This also should make it possible to avoid the use of inNegotiate. What do you think? I think I am going to play a bit with this idea ... :-) Ciao, Mario [1] http://www.ietf.org/rfc/rfc2616.txt [2] http://msdn.microsoft.com/en-us/library/aa479391.aspx -Ursprüngliche Nachricht- Von: Weijun Wang [mailto:weijun.w...@oracle.com] Gesendet: Montag, 10. Oktober 2011 17:33 An: Chris Hegarty Cc: Mario Ivankovits; net-dev@openjdk.java.net Betreff: Re: ntlm with ms exchange server not working since java 1.7 During an NTLM handshake, I've never seen a server mentioning another scheme. As seen in message #4, the NTLM header still contains data, so there should not be WWW-Authenticate: Negotiate header. That said, this is only my experience. I tried to find any words on this from an RFC but failed. -Max On Oct 10, 2011, at 7:48 AM, Chris Hegartychris.hega...@oracle.com wrote: Max [to'ed], Does this look familiar? Is it wrong for the server to be returning WWW-Authenticate: Negotiate during NTLM handshake? -Chris. On 08/10/2011 14:41, Mario Ivankovits wrote: Hi net-devs, I hope you do not mind that I post to this list, but I hope I can provide enough in-depth information about the problem to justify the post here. Accessing a “normal” ntlm protected resource – a simple index.html in an protected directory on an IIS 7.5 server - the ntlm authentication works fine. However, trying to access the Microsoft Exchange 2010 webservice failes with “401 Unauthorized”. I used this few lines to debug the connection/authentication process URL url = new URL(https://exchange/ews/Services.wsdl;); byte[] buf = new byte[10240]; int read = url.openStream().read(buf); System.err.println(new String(buf, 0, read)); This snipped works fine in java 1.6, but failes with an IOException (http status 401) in java 1.7. I found an interesting difference when accessing the “normal” web-page and the exchange webservice. When accessing the web-page, the server answers “WWW-Authenticate: Negotiate” just after the first 401 response which triggers the authentication process then. In contrast, when accessing the Exchange webservice the “WWW-Authenticate: Negotiate” is sent during the negotiation process too, which then triggers the inNegotiate flag in sun.net.www.protocol.http.HttpURLConnection in getInputStream and let the negotiation process fail. If I hack the response values and change any subsequent Negotiate to e.g. NegotiateXX, then the inNegotiate flag will not change and the authentication process will finish and authentication finally
Re: AW: ntlm with ms exchange server not working since java 1.7
On 10/10/2011 12:45 PM, Mario Ivankovits wrote: Hi! back again ;-) To my surprise Digest will be chosen first (this is documented in sun.net.www.protocol.http.AuthenticationHeader, but wrong I think, shouldn't it be read like this: negotiate - kerberos - ntlm - digest - basic) - also no other method will be tried yet. This is not a surprise. In order for Negotiate to happen, you need some Kerberos settings and without them it will not go very long. If I remember correctly, Digest is preferred to NTLM so it's the natural fallback. Just the part, that digest is preferred over NTLM was the surprising part. If you've configured an Swing-Authenticator this will prevent the application from transparently authenticate against the server, no? And then, also that the system did not try to NTLM, after Digest failed, surprises me. I don't think there is a fallback mechanism from Digest to NTLM. If digest fails, then probably the whole auth just fails. You can specify the system property http.auth.preference to NTLM if you always want it to be used. That seems to be the only approach. But I still hope it is a server configuration error. I've checked this against 3 different Exchange Server (2007+2010), all show the same behavior. Two of them are installed by me and one is a server from an exchange server hoster (http://itsolutionsnow.com/) And since my iPhone works against all these 3 server and my Java 1.6 App works too, I don't think this is a server issue. We are just digging in undocumented areas here ... Instead of passing dontUseNegotiate to the AuthenticationHeader, we will pass in a Set of already tried authentication methods. I'm not sure of that. The code logic here is quite fragile and it has underdone several rounds of update and tweaking, and I surely don't like to see anything broken. I see that the code is ... well ... evolved and highly complicated. And I perfectly understand that you would not like to change much here as it seems VERY hard to test. A rather ugly hack is to choose NTLM as long as it has extra parameter(s). Hopefully that's safe. We know NTLM has defined 3 messages and that means the final answer from server is simply 200 OK without any 4th confirmation... Yep, that will fix my main issue, but will not help in trying all the possible authentication methods announced by the server. Why not? If it's the first time NTLM is proposed as a scheme, it should not have any parameter. Therefore, I don't see a possibility that other schemes will be ignored. I haven't touched these codes for some time, and forget if the parsing of WWW-Authenticate header(s) have any difference when it (or they) is presented the first time and during the handshake. I couldn't resist, sorry, attached you will find a diff and the source files I had to change to patch both issues (in my environment at least). I active them in an bootclasspath/p environment. Don't be too curious about AuthenticationHeader2, I just had to rename it to avoid a conflict with javas original class as I changed the constructor. As you can see, the patch is not that big. Which does not mean it doesn't breaks something ... I'll go with them in my test environment for some days. I would be more than happy if you could give it an hour or two to have a look at it. Unhappily, I am sure you might need more time to test all use-cases, but I am still hoping ... ;-) Also, if we'd like to keep Digest before NTLM, I'd vote for adding a property to change the ordering of the authentication methods. But this means have you accept my patch first, else the fallback does not work as expected anyway. That's http.auth.preference again, we now only accept one value for this property, so you can make it NTLM but not NTLM,Digest. I can take a look at the patch, but honestly, I'm so afraid of touching the HttpURLConnection class and its siblings. Thanks Max Well, probably we can (if required, and that is for sure) bugfix my patch and have fixed two issues with it then. ;-) Thanks for your time! Ciao, Mario This also should make it possible to avoid the use of inNegotiate. What do you think? I think I am going to play a bit with this idea ... :-) Ciao, Mario [1] http://www.ietf.org/rfc/rfc2616.txt [2] http://msdn.microsoft.com/en-us/library/aa479391.aspx -Ursprüngliche Nachricht- Von: Weijun Wang [mailto:weijun.w...@oracle.com] Gesendet: Montag, 10. Oktober 2011 17:33 An: Chris Hegarty Cc: Mario Ivankovits; net-dev@openjdk.java.net Betreff: Re: ntlm with ms exchange server not working since java 1.7 During an NTLM handshake, I've never seen a server mentioning another scheme. As seen in message #4, the NTLM header still contains data, so there should not be WWW-Authenticate: Negotiate header. That said, this is only my experience. I tried to find any words on this from an RFC but failed. -Max On Oct 10, 2011, at 7:48 AM, Chris
