[jcifs] No response to NTLM challenge

[Eric Glass]

> Thanks for your reply. To answer each of your questions in turn:
> 
> We are using Apache 2.0.43 /  mod_jk  / Tomcat version 4.1.12 / SunOS
> 5.8.  We are currently using jcifs-0.9.0b.
> 

The problem appears to be possibly twofold, but more on our side.

In jcifs.http.NtlmSsp (line 106), we send the content length to zero explicitly:

    resp.setContentLength(0);

I believe this was done to mirror IIS's behavior (as they set an
explicit content length rather than using chunked encoding).  However,
what your traces show is that the Tomcat error page content is being
sent; so the web server is indicating it has an empty body, but then
sending body content.  I *think* that is what is causing the issue.

There are a couple of steps to resolve this:

1) Try the request against Tomcat directly (rather than going through
the mod_jk connector).  The HTTP listener should send an empty body
(that's what I see, anyways).  This would confirm the root cause of
the issue (the AJP13 listener appending body content when the response
has explicitly specified an empty body).  This part is a minor Tomcat
bug (I think); I would expect the two listeners should be sending the
same thing.

2) We shouldn't have to hardcode a 0 content length; chunked encoding
appears to work fine.  This is a preferable approach, as it would
allow for any error content that the container happens to append to
the response.  The attached version has the fix applied; see if this
works under the mod_jk connector.

3) (not really related to your issue, but similar) -- We currently
send an explicit "Connection: close" in the failure responses (NtlmSsp
line 103, NtlmHttpFilter line 147/162, NtlmServlet line 144/161). 
This isn't actually required, either.  IIS uses the connection to
track the handshake, so they forcibly break the connection to "reset"
the state.  We can leave it open, since we do the handshake
statelessly and use the servlet HttpSession to track the user.  This
significantly improves efficiency, as a single HTTP connection can be
used throughout the whole conversation with the client.  This was the
resolution for the "Davenport uses a huge number of connections"
issue.


Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NtlmSsp.java
Type: text/java
Size: 4518 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20040726/05dfc503/NtlmSsp.bin