[Date Prev][Date Next]
RE: Missing error codes in slapd/backglue.c:glue_back_search() (ITS#1675)
Yes, that's a wonderful spec, but my experience in testing various clients
is that they discard results without presenting them to the user if the
result code comes back with a fatal error. I suppose this can be rehashed
by classifying the error codes into fatal/non-fatal and alter the behavior
accordingly. But again, the point is to create the illusion of a single
here. If one subtree returns ObjectNotFound but other subtrees return valid
results, the result must be considered as LDAP_SUCCESS.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: Hallvard B Furuseth [mailto:firstname.lastname@example.org]
> Sent: Tuesday, March 26, 2002 1:45 AM
> To: Howard Chu
> Cc: openldap-its@OpenLDAP.org
> Subject: Re: Missing error codes in slapd/backglue.c:glue_back_search()
> I wrote:
> > something (gs.err?) should be set to LDAP_<TIME/SIZE>LIMIT_EXCEEDED.
> Or LDAP_ADMINLIMIT_EXCEEDED.
> Howard Chu wrote:
> > The goal was to never return a fatal error code as long as any one of
> > the backends returns a valid result
> I'm not sure that is correct. rfc2251 §4.5.2 says:
> Following all the
> SearchResultReference responses and all SearchResultEntry responses
> to be returned by the server, the server will return a response
> containing the SearchResultDone, which contains an indication of
> success, or detailing any errors that have occurred.
> So apparently existing results _can_ be followed by an error response.
> (And In LDAPv2, a serious error after some results should presumably
> be reported as LDAP_PARTIAL_RESULTS.)