[Date Prev][Date Next]
Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
- From: firstname.lastname@example.org
- Date: Fri, 8 Oct 2010 20:28:00 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
>> Full_Name: Javier Sanz
>> Version: 2.4.17
>> OS: Debian Linux 5.0
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (126.96.36.199)
>> back_meta and back_ldap should forward server controls that clients use in
>> 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
>> 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/