[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