return rc;
}
+static int
+ldap_chain_connection_destroy(
+ BackendDB *be,
+ Connection *conn
+)
+{
+ slap_overinst *on = (slap_overinst *) be->bd_info;
+ void *private = be->be_private;
+ int rc;
+
+ be->be_private = on->on_bi.bi_private;
+ rc = lback->bi_connection_destroy( be, conn );
+ on->on_bi.bi_private = be->be_private;
+ be->be_private = private;
+ return rc;
+}
+
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
static int
ldap_chain_parse_ctrl(
#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
ldapchain.on_bi.bi_db_config = ldap_chain_db_config;
ldapchain.on_bi.bi_db_destroy = ldap_chain_db_destroy;
-
+
/* ... otherwise the underlying backend's function would be called,
* likely passing an invalid entry; on the contrary, the requested
* operational attributes should have been returned while chasing
* the referrals. This all in all is a bit messy, because part
- * of the operational attributes are generated by they backend;
+ * of the operational attributes are generated by the backend;
* part by the frontend; back-ldap should receive all the available
- * ones from the remote server, but then, on it own, it strips those
+ * ones from the remote server, but then, on its own, it strips those
* it assumes will be (re)generated by the frontend (e.g.
* subschemaSubentry.) */
ldapchain.on_bi.bi_operational = ldap_chain_operational;
+ ldapchain.on_bi.bi_connection_destroy = ldap_chain_connection_destroy;
+
ldapchain.on_response = ldap_chain_response;
return overlay_register( &ldapchain );
retry:
rc = ldap_search_ext_s( lc->lc_ld, ndn->bv_val, LDAP_SCOPE_BASE, filter,
- at ? gattr : NULL, 0, ctrls, NULL, LDAP_NO_LIMIT,
- LDAP_NO_LIMIT, &result );
+ at ? gattr : NULL, 0, ctrls, NULL,
+ LDAP_NO_LIMIT, LDAP_NO_LIMIT, &result );
if ( rc != LDAP_SUCCESS ) {
if ( rc == LDAP_SERVER_DOWN && do_retry ) {
do_retry = 0;