[Date Prev][Date Next]
Re: (ITS#5339) wrong referral from back-bdb
Howard Chu writes:
>Hallvard B Furuseth wrote:
>>> Frankly this whole example doesn't make sense, and RFC4511 doesn't say
>>> anything specific about it.
>> Yes it does. Section 4.1.10. Referral:
>> - If the<dn> part is present, the client uses this name in its next
>> request to progress the operation, and if it is not present the
>> client uses the same name as in the original request.
> Yes, I saw that. But the text doesn't give any explanation of the
> ramifications of what it's describing. Which is what I'm complaining
> about here.
Take it up with ldapext:-) And I guess we could make a slapd.conf option
which turns on your preferred way.
The ramifications are that things can break, I think. In particular
DN-valued attributes in the search result or in an Add request. The
server can't help with that either, the client would have to handle it.
Also, now that I think of it, back-hdb/ldif subtree rename is broken if
there are referral objects with DNs in the subtree. So I guess the
slapd.conf option should allow to strip DNs that match the entry DN.
And maybe allow to be more paranoid about rewriting writes (and Binds?)
>> Both RFCs disagree.
> They are wrong. Or at least, under-specified. In X.501 section 17.3
> "Directory Distribution Model" it's quite clear that all of the
> components of a distributed directory must belong to a single DIT.
Which is not true in the LDAP world, and I don't know about today's
X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe
the X.500 world has also switched to 'dc' structure, I don't know.
Anyway, LDAP is not X.500. Remember, LDAP referrals need not even be
LDAP URLs. My guess is that's one reason for the difference from X.500:
When you can even return a HTTP URL, why should you _not_ be allowed
to return a far smaller change from the original URL?
Also LDAP started out a lot sloppier than X.500. Getting some response
which hopefully resembled what you wanted was better than none:-)
> And again, the service model requires the directory to store the
> client's data without any alteration. If the client wants to create
> the entry "cn=me,o=we" either that exact entry must be created, or the
> operation must fail.
Well, the operation does fail in the original server. Then the client
may try another operation at another server... I don't know if that's a
valid interpretation of the service model or not. In any case, it's a
detail compared to the mess