Lars Hesel Christensen XX (AH/LMD) wrote:
Ok, what really confused me when looking at this is the fact that
comments for ldap_result (as well as the man pages) claims that we will
receive unsolicited messages when calling ldap_result with LDAP_RES_ANY
I'm not sure about how to handle unsolicited messages other than notice
of disconnect, but as it is, when the user can just ignore unsolicited
messages, I suppose it would be a good thing if the library itself could
deal with them and dispose of them. I think this is what is intended
when reading the section about unsolicited messages in the RFC. At least
it seems to me that it would be bad/confusing if some unsolicited
messages are handled by the application and some are handled by the
I think it would not be to hard to create a mock-up server that can
accept a new session and then send a notice of disconnection to the
client. That would be a simple way to test that client-side
code/handling of notice of disconnection - whatever the outcome of the
above discussion might be :)
right now HEAD code should allow you to experiment with (almost
arbitrary) unsolicited responses.
The client library right now returns correct unsolicited messages (i.e.
extended response messages with msgid == 0) if requested (i.e. if the
msgid parameter to ldap_result(3) is either set to LDAP_RES_ANY or
LDAP_RES_UNSOLICITED); otherwise, it directly handles the RFC 4511
"Notice of Disconnection" message.
The server allows you to craft a special overlay (slapo-retcode(5))
- return regular response messagess with msgid == 0
- return extended response messages with a given OID and optionally some
extended response data
- disconnect abruptly without notice.
I haven't tested it with in-directory data yet, although the code should
be present. I've only tested it with retcode-item configuration
retcode-item "cn=unsolicited" 0x00 unsolicited="0"
retcode-item "cn=unsolicited-extended" 0x00
retcode-item "cn=disconnect" 0x00 flags=disconnect
See test038 for an example that sets up the slapo-retcode(5) overlay.
To trigger the abnormal behavior, you can search the database using the
"offending" entry as search base, although any operation affecting that
DN should be fine.
Ing. Pierangelo Masarati
OpenLDAP Core Team
Via Dossi, 8 - 27100 Pavia - ITALIA