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
!
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
!
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
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.
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
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
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) -
