directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <...@symas.com>
Subject Re: Paged Search Control questions
Date Sun, 14 Dec 2008 16:41:16 GMT
Emmanuel Lecharny wrote:
> Stefan Seelmann wrote:
>> Emmanuel Lecharny wrote:
>>
>>> Another one :
>>>
>>> suppose we have a normal user doing a search request with a sizeLimit of
>>> 10, with the server limit set to 5, and the potential result would be 7
>>> entries (so the result will be truncated to 5 entries due to the server
>>> limit) :
>>> - should we generate a SizeLimitExceededException ?
>>>
>> Do we generate such an SizeLimitExceededException when doing a normal
>> search request without the paged search control? I guess yes. So I think
>> we should also return an LDAP code 4 here.
>>
> Seems like Openldap behaves this way. So ADS will generate a code 4 if
> the server size limit is exceeded.
>
> Thanks Stefan !

Sorry for jumping in here late, wanted to reply earlier but on dialup right 
now so it's not always convenient... Still, it looks like Stefan covered all 
the bases already.

To summarize: using the Paging control should only be considered a form of 
XON/XOFF flow control for a single Search request. It cannot (MUST not) change 
the server's behavior wrt the overall size limits in effect. MS AD is broken 
in this respect (which is particularly pathetic given that some MS folks 
co-authored the spec, but so it goes). I.e., when no control is present, the 
search result set will be the smaller of the client's requested size limit, 
and any administrative limits configured on the server. With the control 
present, the total number of returned entries allowed is still the same, just 
that they may be received by the client in smaller groups.

Also beware of another issue: the spec says the page size is an Integer but MS 
AD implements it as an unsigned, and there are MS clients out there that 
expect to be able to set the max size (god knows why, since that effectively 
disables paging) and will implode when they receive a ProtocolError in 
response to such an erroneous request. (I've forgotten the ID# of the bug 
report in our tracker...) All in all it's a crummy spec and you can pretty 
much bet that when you run across a client that depends on it, the client is 
broken in a lot of other ways.
-- 
    -- Howard Chu
    CTO, Symas Corp.           http://www.symas.com
    Director, Highland Sun     http://highlandsun.com/hyc/
    Chief Architect, OpenLDAP  http://www.openldap.org/project/

Mime
View raw message