[Date Prev][Date Next]
> Well, thank you very much for your flash-like answer, Mr. Masarati. And
> let me clarify a bit things about part 2 of ITS
>>> 2. Leading and trailing spaces issue.
>>> When I try to rename existing entry (e.g.: with UID or OU RDN's
>>> to the same RDN's value except for additional trailing or leading
>>> escaped ofcourse) the server return "Already Exists" error.
>>leading/trailing chars are removed, unless they are escaped (be liberal
>>you read, strict in what you write). Note that a DN of "cn= something"
>>be an error; a DN of "cn=\ something" is correct, as well as
>>If you use "cn= something", slapd is liberal, and reads "cn=something".
> If I add a new entry with DN in a form of "uid=\ something" everithing
> is ok unless
> "uid=something" does not exists. But if it does, server returns "Already
> Exists". But I'm
> not sure is it a correct behaviour? I mean is it normal that server
> treats strings "\ something"
> and "something" as identical?
OK, this is another point more. I was speaking in terms
of DN string representation, i.e. what a string is parsed
to give a DN. If you consider "uid=something", it is parsed
exactly the same as "uid= something", because spaces around
the "=" are ignored, to be liberal. If you consider
"uid=\ something", this is parsed differenty; so, in terms
of string representation, "uid=something" and "uid=\ something"
differ. The point comes when matching is to occur.
Some attributeTypes, when normalized, require leading, trailing
and multiple spaces to be eliminated; e.g., a "cn" valued
" My Common Name " is equal, in terms of matching rules,
to "My Common Name". So, even if you force the leading space
by writing "uid=\ something", it will be parsed correctly and
represented differently from "uid=something", but when they
are compared (e.g. when deciding if an entry alredy exists),
they do match.
I'd comment that to rely on "uid=\ something" being treated
as different from "uid=something" really sounds like shooting
in one's foot...