[Date Prev][Date Next] [Chronological] [Thread] [Top]

When should backends send results?



With back-relay to back-ldif/back-null, Password Modify fails with
"operation not supported within naming context".  However it works
with back-ldif without back-relay, and with back-relay to back-bdb.

The difference is that back-relay:relay_back_op_extended() does
	send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM,
			"operation not supported within naming context" );
	return 1;
while back-bdb:bdb_extended() does
	rs->sr_text = "not supported within naming context";
	return LDAP_UNWILLING_TO_PERFORM;
and back-ldif/back-null have no be_extended.

It works with back-relay if I change relay_back_op_extended() to do the
same as back-bdb.

back-ldif also lacks a compare, so I tried the same change to
relay_back_op_compare(), but then slapd did not respond to Compare.

So, which backend is right?  Should a backends's or overlay's
be_extended() leave it to the caller to send results, just like
be_bind() at success?  Or should that be done just in some cases?
Is it documented somewhere?

Back-relay also logs two results, I haven't checked if it sends two:
conn=0 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1
conn=0 op=1 PASSMOD id="cn=urgle,cn=db" old new
conn=0 op=1 RESULT tag=120 err=53 text=operation not supported within naming context
conn=0 op=1 RESULT oid= err=1 text=operation not supported within naming context

-- 
Hallvard