[email protected] wrote: > [email protected] wrote: >> Full_Name: Hallvard B Furuseth >> Version: RE24, HEAD >> OS: Linux x86_64 >> URL: http://folk.uio.no/hbf/OpenLDAP/rwmhang-draft.txt >> Submission from: (NULL) (193.157.201.147) >> Submitted by: hallvard >> >> >> rwm suppresses the LDAP response message if rwm_response() fails. >> This hangs waiting for the response: >> >> include servers/slapd/schema/core.schema >> database monitor >> overlay rwm >> rwm-rewriteEngine on >> rwm-rewriteContext matchedDN >> # Rewrite to nonexistent $1 or broken DN >> rwm-rewriteRule ".*time.*" "cn=test,$1" : >> rwm-rewriteRule ".*" "urgle" : >> >> ldapcompare -x cn=hello,cn=time,cn=monitor l:x >> ldapsearch -xLLL -b cn=hello,cn=monitor >> >> The enclosed patch seems to fix it, but I've only looked briefly at >> what's going on. > > Good catch; however, the problem might need a slightly different fix; in > fact, yours prevents rwm_response from aborting the operation by forcing > an "unwilling to perform" based on the contents of the referral/matched. > > However, this is probably conflicting (as in many other cases in > slapo-rwm(5)), with the fact that some operations (e.g. extended) do not > return response directly, but delegate the frontend; or, like the bind > operation, only return unsuccessful results directly, and delegate > successful responses to the frontend.
Perhaps this ITS could serve as a reminder to remove those two inconsistencies from the structure of this code. The historical reasons for Bind's behavior no longer apply. I don't believe there was ever any special reason why exops needed to behave this way. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
