[jcifs] Why would auth work on one server and not on another?

[eglass1 at comcast.net]

> IE, also receives the 'Connection: closed' header, and as per the trace in
> ethereal, actually generates and sends out a 2nd 'get', but yet, on my
> server, I have turned on every flag possible, and no 2nd 'get' request is
> ever made.  It is almost as if IE makes the request, but it doesn't go
> anywhere.
> 
> Again, maybe I am reading the capture incorrectly, so please, correct me if
> I am wrong.

Here's what is happening.

Frames 61-63 are the establishment of the initial connection.

Frame 64 is the initial GET request.

Frame 65 is the first 401 response from the server.  Note the presence of the
"Connection: close" header; this indicates that the server intends to terminate
the connection (as is expected).

Frame 66 is the HTTP response body.  We (the jCIFS filter) didn't send a body;
this indicates that the server is trapping the response.setStatus(401) and
effectively treating it like a response.sendError(401), which closes the
connection and sends an error page (this is okay, since we intended to close the
connection here anyway).

Frames 67-71 are the ACKs and teardown handshake; the server initiates the
connection termination with a FIN, and the client closes its side accordingly.

Frames 72-74 are the establishment of the second connection.

Frame 75 is the second GET, with the Type 1 message.

Frame 76 is the second 401 response from the server, with the Type 2 challenge.
This is where the problem arises.  We do a response.setStatus(401), but *don't*
set the "Connection: close" header; we want the connection to remain open.
setStatus is *supposed* to do this for us.  However, the container is treating
the setStatus as if it were a sendError (probably because we are setting the
status to an error code).  It is setting the "Connection: close" header, which
is bad because it now intends to close the connection, which is not what we
want to happen.

Frame 77 is the container's default error page.

Frame 78 is the FIN from the server, initiating the closure of the connection.
Note, however, that the client doesn't send the FIN to tear down its side of the
connection; instead, it attempts to send the third GET with the Type 3 message
(Frame 82).  This is what causes the container to reset the connection with an
RST in Frame 83; as far as it is concerned, the connection is no longer valid.

Short of hacking your container, there probably isn't too much you can do to
"fix" this.  My guess is that Mozilla is acknowledging the FIN and resubmitting
the Type 3 in a new connection (this is okay with jCIFS, as we don't require
a persistent connection).  I'm not sure if it is a specification or
implementation issue, but your container is treating the setStatus(401) as
if it were a sendError -- closing the connection and sending an error page.


Eric