masarati@aero.polimi.it wrote:

...

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12)

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.

Note that the SSSVLV overlay can handle paged results locally too, thus negating any need for back-ldap/back-meta to forward it to a remote server. Obviously for greatest generality, there needs to be a way to configure which set of controls to pass through, and which to process locally. (Much like back-ldap's option to process the WhoAmI exop...)