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

Dave Mobley scprotz at hotmail.com
Thu Jul 17 05:01:11 EST 2003

Thanks eric,

this is much as I had suspected.  I have a feeling it is the http stack that
is causing this to be a problem (not the servlet manager).

I have a 'work-around' solution for the time being, but it is a nasty hack.
I am going to keep trying to get it to work on this server.  There is a C
api that allows you to delve into the internals of the server.  Maybe I can
'fix' the problem there.

Thanks for all the support, and for those of you looking for NTLM
authentication on Domino, let me know, and I might have something available
at some point in the future.

Dave Mobley
scprotz at hotmail.com
----- Original Message ----- 
From: <eglass1 at comcast.net>
To: <scprotz at hotmail.com>
Cc: <jcifs at lists.samba.org>
Sent: Wednesday, July 16, 2003 9:48 AM
Subject: Re: [jcifs] Why would auth work on one server and not on another?

> > IE, also receives the 'Connection: closed' header, and as per the trace
> > 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
> > 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
> > 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
> "Connection: close" header; this indicates that the server intends to
> the connection (as is expected).
> Frame 66 is the HTTP response body.  We (the jCIFS filter) didn't send a
> 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
> 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
> This is where the problem arises.  We do a response.setStatus(401), but
> set the "Connection: close" header; we want the connection to remain open.
> setStatus is *supposed* to do this for us.  However, the container is
> the setStatus as if it were a sendError (probably because we are setting
> status to an error code).  It is setting the "Connection: close" header,
> is bad because it now intends to close the connection, which is not what
> 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
> 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
> (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
> Short of hacking your container, there probably isn't too much you can do
> "fix" this.  My guess is that Mozilla is acknowledging the FIN and
> the Type 3 in a new connection (this is okay with jCIFS, as we don't
> 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
> Eric

More information about the jcifs mailing list