Subject: When can Search return errors (post name resolution)

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 30 Nov 2004 08:45:04 -0700

How literally are we to take the statement from X.511:
"The request succeeds, subject to access controls, if the baseObject is
located, regardless of whether there are any
subordinates to return"?
 
For example, if an alias loop is detected while searching, is it
silently ignored? Similarly, if an alias cannot be dereferenced while
searching, do we not return aliasProblem?
 
Surely, if there is an internal error (out of memory, etc.) the request
does not succeed. 
 
Of course sizeLimitExceeded and timeLimitExceeded may be returned even
if the base object is located, but in X.511 these are not returned as
ERRORS, they are returned in partialOutcomeQualifier.
 
[Protocol] says this instead:
"   Servers MUST NOT return errors if attribute descriptions or
matching 
   rule ids are not recognized, assertion values are invalid, or the 
   assertion syntax is not supported. More details of filter processing

   are given in Clause 7.8 of [X.511]."
 
I've had it asked whether LDAP implementations are to go beyond this
statement and never fail a search once name resolution has completed (as
is implied by X.511), and specifically, what to do about alias
derefrencing problems while searching.
 
Jim

---

From: Howard Chu <[email-masked]>
Date: Tue, 30 Nov 2004 09:28:47 -0800

I've always assumed this only meant "don't return NO_SUCH_OBJECT if the 
search result set is empty." Certainly other issues should be noted if 
they arise.

Jim Sermersheim wrote:
> "   Servers MUST NOT return errors if attribute descriptions or matching

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

---

From: Steven Legg <[email-masked]>
Date: Wed, 01 Dec 2004 11:51:33 +1100

Jim,

> located, regardless of whether there are any

If one takes the statements in X.500 literally then it is all too easy to
find inconsistencies and conflicts. A fair dose of common sense is required.
I have found it best to look for the point of any statement rather than agonize
over its exact wording. The point of this statement is that it is not an error
if the base entry of a search has no subordinates.

> searching, do we not return aliasProblem?

I give the error descriptions more weight (they are more specific) than
more general statements about success and failure.

> Surely, if there is an internal error (out of memory, etc.) the request 

Yes, that is the common sense approach.

> is implied by X.511),

As it is technically difficult to *force* an operation to succeed in the face
of crippling errors, common sense says to favour the error descriptions over
an imprecise statement regarding success and failure (where there's a conflict).

 > and specifically, what to do about alias

I ignore alias problems within the subtree being searched since they can arise
through legal operations on the directory, and always raising an error would fail
every attempt to search a subtree that happened to contain a flawed alias.

Regards,
Steven