Full_Name: Matthieu Speder Version: 2.3.38 & Latest HEAD OS: Linux URL: Submission from: (NULL) (82.224.96.182) When using pagedresults with a subordinate database, the control value of the returned searchResDone is corrupted. * Config part database ldap suffix "dc=test,dc=com" subordinate uri "ldap://ldap2.test.com:389" lastmod off overlay rwm rwm-rewriteEngine on rwm-suffixmassage "dc=test,dc=com" "dc=mainldap,dc=com" * Query : ldapsearch -x -b 'dc=test,dc=com' '(objectclass=*)' -E pr=10 (...) # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= control:: IGZhbHNlIE1Ba0NBUUFFQkFzQUFBQT0= * Packet decode : Lightweight-Directory-Access-Protocol LDAPMessage searchResDone(2) [0 results] messageID: 2 protocolOp: searchResDone (5) controls: 2 items Item pagedResultsControl controlType: 1.2.840.113556.1.4.319 (pagedResultsControl) SearchControlValue size: 0 cookie: <MISSING> Item controlType: \300\3371\b840.113556.1.4.319 controlValue: 300902010004040B000000 0000 00 0c 29 06 cc dd 00 0c 29 1b ea e9 08 00 45 00 ..).....).....E. 0010 00 8e 7b fd 40 00 40 06 a7 ca 0a 00 01 5d 0a 00 ..{.@.@......].. 0020 01 46 01 85 a8 92 c0 a3 d0 9d 5e c3 30 b0 80 18 .F........^.0... 0030 05 a8 2b 24 00 00 01 01 08 0a 01 16 bf 7a 00 00 ..+$.........z.. 0040 1a e9 30 58 02 01 02 65 07 0a 01 00 04 00 04 00 ..0X...e........ 0050 a0 4a 30 21 04 16 31 2e 32 2e 38 34 30 2e 31 31 .J0!..1.2.840.11 0060 33 35 35 36 2e 31 2e 34 2e 33 31 39 04 07 30 05 3556.1.4.319..0. 0070 02 01 00 04 00 30 25 04 16 c0 df 31 08 38 34 30 .....0%....1.840 0080 2e 31 31 33 35 35 36 2e 31 2e 34 2e 33 31 39 04 .113556.1.4.319. 0090 0b 30 09 02 01 00 04 04 0b 00 00 00 .0..........
changed notes
> When using pagedresults with a subordinate database, the control value of > the > returned searchResDone is corrupted. AFAIK, paged results is not supposed to work with glued databases, as its current implementation in both back-bdb/back-hdb and back-sql relies on internal properties of the storage to keep track of the state of a search. The most appropriate behavior would be to ignore the control, if not critical, or reject the operation, if critical. I take this ITS as an action to prevent paged results from working when impacting more than one glued database. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
ando@sys-net.it wrote: >> When using pagedresults with a subordinate database, the control value of >> the >> returned searchResDone is corrupted. > > AFAIK, paged results is not supposed to work with glued databases, as its > current implementation in both back-bdb/back-hdb and back-sql relies on > internal properties of the storage to keep track of the state of a > search. The most appropriate behavior would be to ignore the control, if > not critical, or reject the operation, if critical. > > I take this ITS as an action to prevent paged results from working when > impacting more than one glued database. I disagree. The fact that databases are glued should in no way prevent paged results from working. After all, the glue only talks to one database at a time. As such, the paged results control's relevance never spans more than a single database at a time. The bug is that after one database has provided all of its entries in response to a request, its response control should be nullified. I.e., a particular database's response control is only needed if that database isn't finished sending entries. Once it has sent all of its entries, it's no longer relevant. Overall the paged results implementation is a suboptimal design; the frontend should do all of the page counting/tracking. It should only ask the backend to provide a state cookie when the current page is full and there are more entries to return. -- -- Howard Chu Chief Architect, 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 Open to Test moved from Incoming to Software Bugs
> I disagree. The fact that databases are glued should in no way prevent > paged > results from working. I mean: the current implementation prevents it from working (AFAIK); I see disabling it in case of glued database a legitimate fix of the problem. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
ando@sys-net.it wrote: >> I disagree. The fact that databases are glued should in no way prevent >> paged >> results from working. > > I mean: the current implementation prevents it from working (AFAIK); I see > disabling it in case of glued database a legitimate fix of the problem. OK. Well, it's working now in HEAD, we can roll that fix for RE24. I don't see much reason to backport to RE23 but am open. -- -- Howard Chu Chief Architect, 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 Test to Release
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
fixed in HEAD/RE24