I just cloned the source, and found where it removes the paging control.

== /* NOTE: this is a quick workaround to let pcache minimally interact * with pagedResults. A more articulated solutions would be to * perform the remote query without control and cache all results, * performing the pagedResults search only within the client * and the proxy. This requires pcache to understand pagedResults. */ static int pcache_chk_controls( Operation *op, SlapReply *rs ) ==

Well, then since you are confirming the bug, I would say this ticket should *not* be closed.

I might just have to patch this to make it work. The client software I'm actually working with is nextcloud, and it is *very* *very* *very* ldap chatty. And with 2900+ objectclass=group, and 3300 objectclass=person, it runs super dog slow. Their suggestion is to install a local ldap instance configured as a caching proxy, which has led us to here.

I've already fixed several issues in nextcloud locally(the first one I ran into was $limit=400 hard-coded in the group search function).

This kind of paged result handling needs to be dealt the same way an http proxy would deal with partial content caches.

On Wed, Sep 6, 2017 at 4:22 PM, Quanah Gibson-Mount quanah@symas.com wrote:

Hi Adam,

I would note that pcache is not back-ldap, so their behavior is not the same.

slapo-pcache strips out the paged results control, and has since 2005 (ec532ce88590c5454025cbc030d9df65d2df634f). So in the 12 years since then, you're the first to have an issue with the behavior. If you'd like to see a change in relation to this, patches welcome.

--Quanah

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com