AW: [jcifs] NTLM HTTP Authentication Filter broken with Tomcat 5. 0.2?

[eglass1 at attbi.com]

I did some further analysis of this.  It isn't the explicit content-length 
causing the server to disconnect; the explicit content-length causes Tomcat to 
change the status from 401/unauthorized to 200/ok.  This is definitely a Tomcat 
bug, and causes the client to give up (because it thinks authentication has 
been achieved, it doesn't bother to send the Type-3 message).  I'll file a bug 
report.  Below is a simple servlet to reproduce this issue:

import java.io.*;
import javax.servlet.http.*;

public class Test extends HttpServlet {
    protected void doGet(HttpServletRequest request,
            HttpServletResponse response) throws IOException {
        response.setContentLength(0);
        response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
        response.flushBuffer();
    }
}

Eric
> 
> > Eric,
> > It works for me after commenting out resp.setContentLength(0) in
> > NtlmSsp.java.
> > Does this problem need to be addressed with the Tomcat developers?
> > 
> 
> Probably.  Technically speaking, it should work both with the Content-Length
> set and without (using chunked encoding).  This workaround should work on
> other containers and clients, but I would really prefer to follow IIS's
> implementation as closely as possible (using the explicit content length).
> There is a much smaller risk of breaking somebody that way.  I'll submit
> a bug with the Tomcat guys.
> 
> Eric