[Date Prev][Date Next]
control combination was: Re: protocol-22 comments)
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 4/16/04 3:45:57 PM >>>
>>However, also consider
>>what to do if the same control appears twice,
>For most controls, that's a protocol error. Unless the control
>specification says the control can appear multiple times, it cannot.
>This should be made clear in [Protocol].
Actually, this is clear (see combination of controls in 4.1.11), but
the current language says behavior is undefined.
>>but containing different
>>parameters, and the control is implemented by setting a variable for
>>operation to that parameter. With the current text, the server is
>>required to always pick e.g. the parameter with lowest value, instead
>>just using the parameter in the last control. Or it could detect the
>>situation and return unwillingToPerform, but then it will still need
>>extra state info in order to notice the situation.
>I am curious as what current implementations do when presented
>with multiple controls of the same type within a single PDU.
>OpenLDAP, IIRC, treats this as an error condition.
I think treating as an error is the best policy. This is really no
different than combining two different controls. If the spec doesn't say
what should happen, then behavior is undefined.
We currently recommend that clients not do this. I propose recommending
that servers return an error, but allowing them to handle these cases in
an undefined way.
If we do recommend it, we need to recommend an error code. I prefer
protocolError, but it's documented as having a very specific meaning
followed by a growing list of exceptions (this would add to that). A
second choice is unwillingToPerform.