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

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap

> Full_Name: Javier Sanz
> Version: 2.4.17
> OS: Debian Linux 5.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (
> back_meta and back_ldap should forward server controls that clients use in
> their
> queries to the corresponding external LDAP servers.

Both back-ldap and back-meta forward controls to the remote servers.

> For example, the inhability to send controls to external servers currently
> causes that RFC2696 paged results control cannot be used, so it is
> impossible to
> retrieve more results for a query than the page size configured in the
> external
> server, which often is not a big number.

As far as I can tell, back-ldap supports paged results correctly (just
tested with HEAD and 2.4.23 code).  Back-meta does not, and likely will
never do.  Please note that while all back-ldap needs to do is blindly
forward control request/response, back-meta would need to separately
handle requests server-side (i.e. when the client requests the control)
and client-side (i.e. when non LDAP-compliant remote servers return the
control while the client did not request it).  In between, it would need
to return the page size requested by the client and store the (possibly
paged) response of each remote server.  Not worth the effort.  The
solution consists in increasing the page size returned by default by
non-LDAP compliant remote servers.

Perhaps the problem could be split in two:

1) allow to configure per-target mandatory use of paged results, with a
specified page size; this means that search requests hitting a specific
target would always add the paged results control to the request, and
handle control responses accordingly.

2) handle server-side control response in an overlay that takes care of
storing search results and returning them as appropriate.  This would
(maybe inefficiently) handle paged results regardless of the backend that
is actually handling a request.

Even if only (1) is implemented, clients would no longer need to use pr
when talking to slapd, since back-meta would handle non-LDAP compliant
remote servers that return pr response when the control is not requested.

I think this ITS should be closed (back-ldap and back-meta do forward
controls); maybe another ITS with a back-meta feature request to handle
non-LDAP compliant remote servers could be filed.