[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/clients/tools ldapsearch.c

At 03:25 PM 6/21/2004, Howard Chu wrote:
>Kurt D. Zeilenga wrote:
>
>>I'm presently thinking it better to lower the effective limit
>>to the hard limit instead of treating the too high limit
>>request as an (adminLimitExceeded or like) error.
>
>Doesn't that sort of negate the purpose of the AdminLimitExceeded error code then?

The revised LDAP TS (a work in progress) specifically notes
that servers may enforce administrative size/time limits in
addition to those requested by the client and, when violated,
return size/timeLimitExceeded errors.  One can view
administrative size/time limit result codes as being more
specific than the administrative limit result code, allowing
the user (client) to distinguish size/time limits from other
administrative controls which might be exceeded.

I would argue that returning adminLimitExceeded or
unwillingToPerform would be more appropriate if we were
to return immediately upon noticing the requested limits
were greater than the administrative limits.  However,
if we instead process the operation, then I think
size/timeLimitExceeded are better.

At present, I'm thinking it better to process the
operation under the lowered limits than to immediately
return an error.


>>At 02:25 PM 6/21/2004, Pierangelo Masarati wrote:
>>
>>>>At 11:03 AM 6/18/2004, Kurt D. Zeilenga wrote:
>>>>
>>>>>In slapd(8), if the user requests sizeLimit=0, they get the
>>>>>soft limit.   If they request sizeLimit>0, they get that limit
>>>>>as long as it is not greater than the hard limit otherwise
>>>>>an error occurs.
>>>>
>>>>s/otherwise an error occurs/otherwise the hard limit is used/
>>>>
>>>>(which is what I think the current slapd(8) behavior is)
>>>
>>>I confirm, the current behavior is that an error occurs
>>>if a limit greater than hard is explicitly requested
>>>by the client.  I've found the message thread where the
>>>limits behavior was designed.  Unless amended in later
>>>messages (I didn't follow the whole thread), this is what
>>>we agreed at the time.
>>>
>>>http://www.openldap.org/lists/openldap-devel/200107/msg00126.html
>>>
>>>Of course, we can amend it now; however, now the "max"
>>>mechanism allows to directly hit the hard limit, if any.
>
>
>
>-- 
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support