On Sat, Jan 24, 2009 at 3:19 PM, Howard Chu <[email protected]> wrote: > Unfortunately, I think the spec is broken here. There's no way for the > consumer to record the references it receives, because they're not > accompanied by the DN of the entry that triggered the reference. It would > have made more sense for the provider to send the references uninterpreted, > as regular LDAP entries. > > Any suggestions? >
It would make sense for a syncrepl to send the referral without any modifications or de-referencing, IFF the entity querying is also syncrepl. Because syncrepl is only replicating state of a DIT (it is in itself not really interested in the data a referral might return) and is not and "end user", it should act as if it is "managing" referrals, and not-de-referencing them. I'm assuming, the intent of a referral is to make a reference to some other data for a "end user", and usually because that data is of a somewhat transient state, or that it is a delegation to another server for which the local server is not authoritative. I think the referral should be copied without de-referencing by syncrepl, then when a "end user" asks for that same data from the replica (querying the replica to which the entry has been replicated by syncrepl), they will get data de-referenced at the time of thier query, rather than getting some stale re-referenced data that syncrepl may have copied some (perhaps a very long) time ago when the data was replicated and de-referenced by syncrepl. So probably as a consequence syncrepl client should ask for referrals to not be de-referenced, or the server should not de-reference referrals by default IFF the query is part of a syncrepl session. This assumes the server can easily distinguish a syncrepl client from a "end user". But it means the replica would de-reference referrals closest to the end user, which seems to best preserve the intent of a referral IMHO. Cheers Brett
