|
<snip>
>I am not suggesting that servers do any back-tracking to mitigate the >failures encountered while processing a request accompanied by >non-critical controls. Only stating that the presence of a non-critical >control should not cause a server to choose not to *begin* executing the >accompanying request. Once the server has decided to begin executing the >request, any incidental errors should of course be reported back to the >client as usual. Servers deciding what it means to "begin execution" is what will cause confusion and different implementations to behave contrary to clients expectations. Some servers might, during the process of name resolution, discover that the non-critical control is not allowed or supported in that part of the tree, and drop it. If this is a "dereferenceAliases" control, then dropping it at this point may constitute partial service of the control. If it's a different control, it may be safe to ignore the control after, or during, name resolution.
Some servers might evaluate a search request, apply the filter to the backing database, and not until the first object candidate is located peer into the ber packet holding the attribute selection list. At this point the server may decide that a non-critical control is at odds with something in the selection list. Now, this server may safely ignore the control, but ignoring the control might (or might not) require the server to re-apply the original filter to the backing database, so instead, it might just choose to fail the operation.
Re-reading your original post, I think slapd is being overly strict anyway. The control was in fact not recognized by the ultimate service it was sent to and thus should have been dropped (if not also being used in other contexts). This is the same as a non-critical control attached to a request which immediately chains to another server (with no part of the operation being affected prior to the chaining). In other words, if the server can determine that the non-critical control is not recognized or appropriate for the operation, then it can ignore it (as long as it can ensure it will not be applied partially). Changing the definition of appropriate *might* alleviate part of your original concern, and it might not. If a non-critical manageDSAit is attached, it can be ignored if it is known that it will only be applied to a single context/backend. But if the request can span backends, or will be chained, then the original problem is still there.
|