[jcifs] NTLM HTTP Authentication Filter broken with Tomcat 5.0.2?

[eglass1 at attbi.com]

Marc,

Do you see anything on the HTTP side (i.e., from your browser)?  I was able to 
get Tomcat 5 working, although I had issues different from what you are 
seeing.  From what I experienced, Tomcat was closing the connection when the 
Type-2 message was sent; the client was then giving up and just displaying a 
blank page.  I was able to rectify this by removing the

resp.setContentLength(0);

line from NtlmSsp.java.  Tomcat's behavior seems to be inconsistent with RFC 
2616, which states:

   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
   maintain a persistent connection unless a Connection header including
   the connection-token "close" was sent in the request. If the server
   chooses to close the connection immediately after sending the
   response, it SHOULD send a Connection header including the
   connection-token close.

That is, if Tomcat intends to close the connection, it should send 
the "Connection: close" header with the response; likewise, if we don't set 
the "Connection: close" header, it should keep the connection alive.  Removing
the explicit content length allows the container to use chunked encoding; 
apparently, this triggers Tomcat 5 to keep the connection alive (or rather, 
Tomcat is deciding to close a connection with an explicit content length, and 
this prevents that behavior).

Theoretically, changing this shouldn't cause any adverse behavior.  However, 
IIS does use an explicit content length; we would have to do extensive testing 
to ensure that this doesn't break other clients or containers.  Either approach 
is technically correct with regards to the RFCs; I would be very hesitant to 
vary from the IIS way of doing things, however, given the delicate nature of 
NTLM negotiation.

I don't know if this addresses the issue you are seeing or not.  Mike, is it 
possible that the initiation of the SMB session occurs when the Type-2 
challenge is created?  If so, is it possible that the exception is just the 
thread dying due to the client never coming back to respond to the challenge?  
I'm not that familiar with the low-level SMB stuff, so I'm not sure exactly 
when the transports, etc. are established.  Mike should be able to tell you 
that.

Try commenting out the setContentLength(0) line and see if it starts working; 
in any case, Tomcat's behavior should probably be regarded as a bug.

Eric

> Mike, Eric, All!
> Just to let you know that the situation is the same with jcifs-0.7.7 and
> Tomcat 5 nightly build as of 2003-05-27.
> 
> Regards,
> Marc