I tried to create a property with an "&" char in the value. proppatch calls the XMLPrinter to prep a property element for transmission to the server but the writeProperty method called is not the variant that formats the value with a CDATA wrapper which means that chars like <, >, & etc can be included in the property value. The patch I have tested in my own client config is to change the default operation of the writeProperty methods to wrap all property values with CDATA. This will not affect the actual value of the properties simply allow them to contain XML syntax chars like &, < and >.
Created attachment 13497 [details] patch to XMLPrinter.java
accepting and will commit when i get committer account.
(In reply to comment #2) > accepting and will commit when i get committer account. I believe this patch is going to cause a problem with using the proppatch method to properly modify properties that validly contain descendants. For example, the auto-version property looks like: <D:auto-version> <D:checkout-checkin/> </D:auto-version> If you wrap the value as CDATA then the proppatch won't work. Similary for other properties that have valid XML structures for their "values". The real issue is that the proppatch/XMLWriter methods are using strings to represent the XML structure and the special entities are not properly escaped. Will this cause issues with properties such as D:displayname and D:comment that aren't normally CDATA?
Yep, you're right. This patch will cause problems for XML encoded values passed to proppatch. Since the XMLWriter can't distinguish XML values from plain string values I guess I must just assume that passing XML encoded String values is the requirement and that if I want to pass plain string data then I need to escape it myself. In which case I'll cancel this defect and put the CDATA wrappers in my calls to proppatch instead. The existence of a writeProperty method that actually escapes the string value for you made me think that it was supposed to be doing it. Thanks for catching this. I wouldn't have noticed a problem since I only proppatch the "displayname" property currently but others would have had problems.
Not a problem, I have been hunting around many of the low level method calls these days during evaluation of how to write a CMS front end using the client API, I have noticed quite a few issues like this that I am making notes of along the way. Hopefully I will be able to get some time to contribute my findings back in the way of patches in the near/mid future.