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

[hyc@symas.com]

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...)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/