Re: commit: ldap/servers/slapd slap.h controls.c

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:23 PM 6/15/2004, Pierangelo Masarati wrote:
>> I think this change should be backed out.  The specification
>> here is flawed here for a number of reasons.  First, because
>> completely ignoring such a pagedresult control can lead to
>> masking of other errors, such as protocol errors due to
>> attachment of two pagedresult controls to the request.
>
>I think the specification is clear in this point; if it's flawed that's
>somthing I can't tell.

Well, I think you are also being overly elevating a
"should ignore" to a "will completely ignore" or "MUST
completely ignore".

The language "should ignore" does not imply an absolute
imperative.  I think it simply meant that were
sizeLimitExceeded is returned, no paging occurs.

But I don't think it meant the server should otherwise
ignore the control.  The server should parse the whole
control (including the cookie) (returning errors as
appropriate), should abandon if requested, should detect
protocol errors due to combination of this control with
other controls, etc..

>In any case, I think my essential point was to introduce
>the possibility of ignoring a control, in case slapd deems
>it appropriate, and make the pr a bit rfc-compliant, since
>I happened to read it again :)

This (the general "ignore" mechanism I find even more
problematic at is counter to what RFC 2251 implies.  If
a control is recognized and appropriate for the operation,
the server is to make use of the control.  So, any
ignoring of this control must be part of making use of
it, not a general control capability.

Your point about reducing work in slapd in this
pagedresult case is valid.  My suggestion here is to
set the o_pagedresults_size to -1 (or other negative
value) and use that to disable paging work.

Kurt