directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: Paged Search Control questions
Date Sat, 13 Dec 2008 20:31:31 GMT
Emmanuel Lecharny schrieb:
> Hi guys,
> as I'm busy implenting this control, 


> 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

> 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

> - 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.



View raw message