Howard Chu wrote:
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.
Yep, and you confirmed that he was plain right :) Sometime, when you try
to implement something, you'd better ask those who 'know' :)
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.
This was a part of the spec I mis-understood, clearly. It makes a hell
of sense to consider that the sizeLimit is global, ad should be
considered across the multiple paged searches. The funny part is that I
have injected such a counter in the internal structure before asking the
question, I don't know what for, and now, I see the reason. The
reptilian part of my brain knew it ;)
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.
On don't see where is the problem here ... Suppose you have a server
size limit (SL), a request size limit (RL) and a paged size limit (PL),
the expected behavior when not using the control should be :
- return min( SL, RL) entries
and if the control is present :
if ( PL < min ( SL, RL ) )
while ( count < min( SL, RL ) ) do
return PL entries or less
count += number of returned entries
done
else
return min( SL, RL )
so in the second case, the client will receive entries in PL sized
groups, until we reach the server limit or the request limit ?
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)
MS client, you mean the utterly crap named LDP ? Ok, we have to take
care of that, and consider that a negative number means something like
the max number of entries then. Easy. Thanks for the warning :)
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.
That's the funniest part of the job : deal with other's errors when you
already have enough of your own in your plate !
Thanks Howard !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
