Pierangelo Masarati wrote:
Lars Hesel Christensen XX (AH/LMD) wrote:
Do we have a test case testing notice of disconnection? I tried to grep the 'tests' directory for 'notice', 'disconnection' and 'unsolicited' but nothing came up.
Perhaps I'm misunderstanding something here, so if I am I would very much appreciate a hint.
Lars,
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 handled by the client library, since RFC 4511 seems to give implementors a lot of freedom.