Emmanuel Lecharny schrieb: > Hi guys, > > as I'm busy implenting this control,
Cool > 1) considering that we have a server sizeLimit, a request sizeLimit and > a page size limit, I'm wondering if we can simply ignore the request > size limit. The page size limit can change, even if the paged result is > being processed, but the RFC says "If the page size is greater than or > equal to the sizeLimit value, the server should ignore the control as > the request can be satisfied in a single page". Should I consider that > the 'sizeLimit' is the request sizeLimit ? My personnal bet is : yes. Yes, I would say the 'sizeLimit' is the request sizeLimit. I think we should not ignore the requst sizeLimit, I would consider it as client-side limit for the complete search over all pages. Say the request sizeLimit is 10 and the page size is 8 for both requests then the first result contains 8 entries and the second contains 2 entries plus a LDAP error #4. > 2) so second question : what if in one of the subsequent requests, the > page size limit is changed and is superior to the sizeLimit ? This > request sizeLimit cannot have changed, otherwise the search request > would have been considered as a new search ( "...a searchRequest with > all values identical to the initial request with the exception of the > messageID, the cookie, and optionally a modified pageSize..."). My > personal guess is again to consider that we should deliver as much > entries as we can, up to the sizeLimit, and generate a LDAP error #4 : > sizeLimitExceeded. Again, I think the request sizeLimit is the total number of returned entries. > 3) regarding the search request immutability : it's pretty hard to check > that the filter hasn't changed, as it may be a complex one, with a > different structure and a a different order. I think that this > constraint is fully absurd, as the client will obviously create one > request, and send a null cookie every time it will send a new paged > search, so I don't see the validity of such a check. Nevertheless, > should we try to implement such a check ? My personal guess, again, is > that it's useless. To check if the filter changed logically is really complex. I think you could just check if the string representation or the bytes the are received were changed. > I'm also interested to have some feedback about how this control is > handled by the other ldap servers, considering the many factors > influencing this control : > - internal server size limit Here different implementations are different. - OpenLDAP just stops if the server side limit is exceeded. - For MS AD has a default server side limit of 1000, but when this control is used you could get more > - how many of such paged search can be handled for a single client Infinite? > - what happens when we send a bad cookie to the server Either start a new search or return an error > - what happen when we play with the sizeLimit parameter You mean the request sizeLimit? If it is changed it should be considered as a new search. > Last, not least, as we are using cursors to get the entries from the > backend, we are able to move forward or backward. It would be > interesting to extend this control to allow a backward pagedSearch (for > instance, providing a negative paged size). Would it be interesting ? There is another control for this: VLV, see [1]. But is also need server-side sorting. Regards, Stefan [1] https://issues.apache.org/jira/browse/DIRSERVER-1265
