- **summary**: imm: long DN attribute values are not handled well if client
does not support long DNs --> imm: long DN attribute in search/accerror result
must cope with client capabilities.
- **Comment**:
Changing this ticket to focus only on the search/accessor result issue.
It makes more sense to check for long DNS on the server side while
generating the result. A flag is appended to the reply indicating if any
long DNs are included in the result. This is a node local protocol change
and is thus safe.
For searches (which in general result in an iteration) there are two
options for how the imma library side could handle the long-DNs-included
flag.
The client library could report ERR_NAME_TOO_LONG already on the
serch-initialize if the client does not support long DNs. This is a
simple solution but has the drawback that it could cause backwards
compatibility problems. Supporting long DNs is by its very nature not
backwards compatible so this is still a reasonable approach.
The alternative is that the client uses the flag to enable a scan
(in the library) for each search-next, to locate exactly which
objects have long DNs or include long DNs in the attributes.
If any long DN is found for that object, then ERR_NAME_TOO_LONG is
returned for that search-next.
The question here is if this second approach makes any sense.
Legacy applications that dont support long DNs will in general not be
prepared to receive ERR_NAME_TOO_LONG either. And upgrading a legacy
application to handle ERR_NAME_TOO_LONG on searchNext could also be
questioned since then one could just as well upgrade the application to
cope with long DNs, at least to the extent that it does not crash when
seeing them.
A third approach where the iteration silently skips over a searchNext
that contains longDNs is rejected because that breaks the semantics of
the API itself. The obvious riks is that the application does not
receive data that is logically included in the scope it is trying to
obtain information for. To silently provide a different scope would
in general be unnaceptable, causing not just problems but probles that
are very fifficult to troubleshoot.
A "filter" could be added to the search request expression allwoing the
client to explicitly state that it wants the search filtered to only
include non long DNs. But this would be quite a big enancement and can
not be done in 4.5.1
---
** [tickets:#1206] imm: long DN attribute in search/accerror result must cope
with client capabilities.**
**Status:** accepted
**Milestone:** 4.5.1
**Created:** Mon Nov 10, 2014 03:40 PM UTC by Zoran Milinkovic
**Last Updated:** Tue Nov 11, 2014 02:41 PM UTC
**Owner:** Zoran Milinkovic
Long DN attribute values are not handled well if a client does not support
long DNs.
In searchNext, the client can get long DN values in object name and SaNameT
attributes.
In accessorGet, the client can get long DN values in SaNameT attributes.
OI callbacks can get long DN values in SaNameT attributes.
If searchNext and accessorGet have long DN in the result, functions will not
return any result, and the error code will be SA_AIS_ERR_NAME_TOO_LONG. This
error code will not break the search, and the client can continue with next
search result.
If OI callback contains long DN in its parameters, OI callback will not be
processed up to the client, and the library will return appropriate error code.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
