Pierangelo Masarati wrote:
Lars Hesel Christensen XX (AH/LMD) wrote:
> Do we have a test case testing notice of disconnection? I tried
> the 'tests' directory for 'notice', 'disconnection' and
> but nothing came up.
> Perhaps I'm misunderstanding something here, so if I am I would very
> much appreciate a hint.
AFAIK there's no handling, in OpenLDAP's code, of "Notice of
Disconnect". Your analysis is correct, the message will be ignored
since no request can be found for it. Note that there's no means, right
now, to test this condition within OpenLDAP since its server side
implementation never returns that message.
Well, the server will send it for unrecognized request types, as well as
incorrectly formatted Controls attached to requests. Of course it's still
true that we don't have any client tools that generate these erroneous
messages. You can in fact see the server send Disconnect messages while
processing the PROTOS or PROTOVER test suites, for example. But in each of
these cases, the Disconnect is sent because of an incoming request, so it's
not the completely spontaneous event that "unsolicited" implies. Certainly we
don't have any detection of an invalidated security layer, which could prompt
a LDAP_STRONG_AUTH_REQUIRED error code.
The point, at the client
library side, is: how should this be handled? I mean: if the caller
requests "msgid == LDAP_RES_ANY", then the message can be returned, and
that's it; otherwise, any unsolicited message should not be queued, but
either dealt with by the library, if known, or ignored. This because,
in principle, multiple unsolicited messages could be returned, and they
would share the same msgid (0).
In the case of notice of disconnect, the library could determine it
should no longer expect any message from the server and, as soon as the
client tries to submit a new request, or asks for response to a pending
request, it should return something like LDAP_UNAVAILABLE or a (yet to
be defined) specific return code.
I guess the main point of the message is to let the client know that the
connection has disappeared because of a server-side decision and not because
of a network failure. So it would seem we should define a new return code for
this purpose. Meanwhile, if the disconnect carries the PROTOCOL_ERROR or
STRONG_AUTH_REQUIRED results, it may be sufficient to just remember them and
return them on subsequent client calls.
I think we should discuss details of how this is supposed to be
by the client library, since RFC 4511 seems to give implementors a lot
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/