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

[Dave Mobley]

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
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
>
>