[Date Prev][Date Next] [Chronological] [Thread] [Top]

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
namespace
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
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
> 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()
> (ITS#1675)
>
>
> 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.)
>
> --
> Hallvard
>