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. 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.
changed notes
changed notes changed state Open to Suspended
> 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. p.
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/
> 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...) Right. With proxies the problem is twofold: a) clients request pr because they think they're talking to AD b) the proxy may need to use pr even if the client does not request it, because it knows it's talking to AD In (a), the issue could be handled the way sssvlv does, relieving the proxy from having to deal with server-side pr; this would be extremely beneficial, for example, for back-meta In (b), the proxy could be configured to use pr the way I mentioned above; in principle, the proxy could be so clever to avoid using pr, and simply accept to handle unrequested pr responses, but only if instructed to do so. Filtering what controls are passed thru should be easy, since both proxy backends always call ldap_back_controls_add()/meta_back_controls_add() to muck with request controls (usually to add proxied authorization and so); this function could easily strip or add pr if instructed to do so. p.
masarati@aero.polimi.it wrote: >> 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...) > > Right. With proxies the problem is twofold: > > a) clients request pr because they think they're talking to AD > > b) the proxy may need to use pr even if the client does not request it, > because it knows it's talking to AD > > In (a), the issue could be handled the way sssvlv does, relieving the > proxy from having to deal with server-side pr; this would be extremely > beneficial, for example, for back-meta > > In (b), the proxy could be configured to use pr the way I mentioned above; > in principle, the proxy could be so clever to avoid using pr, and simply > accept to handle unrequested pr responses, but only if instructed to do > so. > > Filtering what controls are passed thru should be easy, since both proxy > backends always call ldap_back_controls_add()/meta_back_controls_add() to > muck with request controls (usually to add proxied authorization and so); > this function could easily strip or add pr if instructed to do so. Should also revisit ITS#4591 while thinking about this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Suspended to Test moved from Incoming to Software Enhancements
> back_meta and back_ldap should forward server controls that clients use in > their > queries to the corresponding external LDAP 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. I've patched back-meta in HEAD: if you add the "client-pr" directive, it will perform the client-side of RFC 2696 paged results (either always, with the specified page size, or in response to unsolicited paged results response). This will be totally transparent to the actual client, so the client no longer needs to perform paged results itself. Please test and report. Thanks, p.
changed notes changed state Test to Release
changed notes changed state Release to Closed
slapd-ldap works as intended slapd-meta forwards controls pr handled differently in slapd-meta in HEAD fixed in RE24