|
I believe this is what our chaining server does as well, though we have talked about changing chained controls to be critical in the past.
I think your work around could be implemented and render (somewhat) expected effects:
Say a search operation has attached to it a non-critical control (which the DSA supports). When the local DSA chains, it forces it to be critical.
If the operation was chained before the control was used in processing the operation, then any resultCode returned from the chained-to DSA would be preserved.
If the operation was chained during operation evaluation after being partially supported by the local DSA, and if the chained-to DSA returned unavailableCriticalExtension, the operation could return a different error (which would indicate that the operation could not be completed as specified).
>>> Mark Ennis <mark.ennis@acm.org> 3/29/05 6:11:00 PM >>> As indicated in the message Jim referenced, our server will ignore the criticality flag of a control it recognises. However, this does not entirely address the issue Howard raised. In a distributed environment, a server receiving a request may need to chain this request to a number of other servers, where the support of various controls in the different servers may be different. Where a given server receiving a chained request does not support a control, it will base its processing decision on the criticality of the control. So even if the server which received the request from the client can support a given control, the control will potentially be ignored for some part of the result set. This results in the effective behaviour of the server, which received the original request from the client, ignoring the non-critical control for some contexts, even though it does support the control. This is the way our server effectively behaves. The only way around this, at present, would seem to be to force all the controls in a chained request to be critical, which would seem to be counter to the client's request that the processing of a non-critical control is optional. Our policy is to handle controls, in general, in the way John McMeeking described, which is to ignore unsupported and inapropriate non-critical controls. - Mark. Jim Sermersheim wrote: >>From another vendor: > http://www.openldap.org/lists/ietf-ldapbis/200403/msg00055.html > > >>>>"Jim Sermersheim" < jimse@novell.com > 3/29/05 5:08:37 PM >>> > > > Our implementations do this: > > Is the control recognized and appropriate (as specified) for the operation? > Yes, process the operation > No, Is it marked critical? > Yes, fail with unavailable critical extension > No, Ignore the control and process the operation > > This has been discussed at length in the past, and consensus was that this was the original intent and that this is what should be conveyed in the new document. > > IIRC, there were interoperability side effects of allowing "appropriate" to mean anything the server wishes it to mean. > > Jim > > >>>>"Kurt D. Zeilenga" < Kurt@OpenLDAP.org > 3/29/05 12:14:07 PM >>> > > At 10:01 AM 3/29/2005, Jim Sermersheim wrote: > >>Appropriate means that the control specification says it can be applied to that operation. I can add that clarification. > > > That seems what the WG has concluded, but I still for wonder > if that's best. It certainly seem counter to how many > implementor have interpreted the RFC 2251 language, as well > as quite counter-intuitive to me. > > To test the waters, I implemented code in OpenLDAP 2.3beta > which behaves as the WG concluded. If a client asks for > paged results (regardless of critical), the server returns > unwillingToPerform if it cannot honor this control for > the particular search operation requested. However, this > is not the behavior client developers seem to expect. They > assume that if the client says paging is not critical > to them, that the server should simply ignore the control > if it not willing to honor the control for that operation. > > It seems they expect this behavior, not only based on how > they RFC 2251, but how many current servers behave today. > I wonder how other servers which have different capabilities > in different contexts behave? I understand that many servers > support configuration and monitoring contexts, it is likely > that these contexts do not support all the same capabilities > of DIT contexts. So, are there cases in your server > (or other servers you are familiar with) ignores a > recognized non-critical control attached to an applicable > request? (applicable here meaning that the technical > specification indicated the control was appropriate to that > kind of request) > > Personally, I think the logic that RFC 2251 was intending > was that a server should not apply non-critical controls to > portions of the operation. It must up front (before > initiating the operation) make a determination whether > to make use of the control or to ignore it. Once > it does choose to make use of the control in the operation, > there is no going back. This implies, for instance, that > if a client asks for non-critical FOO and the server > involves other servers in the evaluation of the operation, > that all the servers involved must either all provide > paging or none provide FOO. If the first server decides > to provide FOO, then it must indicate to the other servers > that FOO is now critical. If the first server decides > not to provide FOO, then it must indicate to the other > servers that FOO is not to be provided (e.g., remove the > control). > > Kurt > > > > > > |