John Calcote wrote: > > That's exactly what I meant. In fact, there's no other way to do it when > using slptool, as it accepts full element lists on the command line - if the > user doesn't escape strings manually when passing the list, how will any of > the code know which commas are element separators and which are embedded? Yes, your previous follow-up clarifying what you meant made that evident. I agree with what you are saying here. > > ... > > The problem appears to be that the Java API takes more upon itself than it > should. Yes the Java API escapes all strings, see ServiceLocationAttribute.escapeString. It seems the fix is to remove the calls to this function (and the associated unEscape function) and just leave that function exposed for applications to call themselves.
Jim > >>> On the other hand, receiving code must be careful to parse lists into >>> elements before decoding them so that the element list can be parsed >>> properly. If decoding is done first, then the receiver won't know >>> which commas are meant to separate elements, and which ones are part >>> of data strings. >> I think the cause of my concern is the following statement from section 5 >> >> "The<attr-list>, if present, MUST be scanned prior to evaluation for >> all occurrences of the escape character `\'. Reserved characters >> MUST be escaped (other characters MUST NOT be escaped). All escaped >> characters must be restored to their value before attempting string >> matching." > Yes, this is a sore point and one of those places where the slp designers > probably disagreed and missed the lack of alignment in the final analysis. > This paragraph is not even self-consistent. Consider: The subject is > "<attr-list>", which by definition contains characters that must not be > escaped, but which are reserved characters (e.g., the element separator - > comma). In other words, it must contain unescaped reserved characters, but > it also must be processed at this point to escape all reserved characters. > The only reasonable way to manage this is to have<attr-list> be fully > escaped before being processed at this level. > >> This seems to imply that the server and the client have to scan the list > and >> convert escaped/reserved characters, at least the '\' character, but I > think the >> second sentence indicates all reserved characters MUST be dealt with. It > doesn't >> appear OpenSLP is doing that. > A very literal interpretation that also works would have the caller escaping > only those characters that make the caller's intent unclear - embedded list > element separators. Then the slp UA would escape the rest. That seems wrong > in several ways (to me). > > I think we need to remove the internal escaping code from the Java API and > provide escaping functions in the public interface, like the C API does. > > Regards, > John > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Openslp-users mailing list Openslp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-users
