[ http://issues.apache.org/jira/browse/AXIS-2025?page=comments#action_12314561 ]
Shankar Unni commented on AXIS-2025: ------------------------------------ I absolutely can't BELIEVE this!!!!!! You're missing the point COMPLETELY. PLEASE REOPEN THIS BUG. When I use Axis to create an XML/RPC stub, the XML is NOT AN END TO ITSELF. I"m not using Axis to "compose XML". I'm calling a remote API, AND PASSING IT A LEGAL STRING AS AN ARGUMENT. Axis stubs simply act as a convenience stub to generate the transport bytes to make this happen. The KEY POINTS here are: * 0x3 IS A LEGAL CHARACTER IN A STRING * Axis professes to take an API with a String parameter, and pass the string from the server to the client. * Ergo, AXIS is responsible for ensuring that the string is transported SAFELY. The problem that "0x3 is not legal XML" simply means that ***AXIS*** (whose job is to get one string from one place to another) must take not to send that string as naked XML. This ***BUG*** makes it utterly impossible to write any sort of sane String API, because you have to manually intercept *EVERY* string at every API, and encode and decode it yourself. Why the heck would I use a stub generation API if I'm going to have to manually encode and decode every string passed to every API? > Illegal XML characters in String arguments and return values cause XML > exceptions in Axis calls > ----------------------------------------------------------------------------------------------- > > Key: AXIS-2025 > URL: http://issues.apache.org/jira/browse/AXIS-2025 > Project: Apache Axis > Type: Bug > Components: Serialization/Deserialization > Versions: 1.2 > Environment: All (but reproduced on WinXP). > Axis 1.1 and 1.2 > Reporter: Shankar Unni > Assignee: Venkat Reddy > Attachments: Axis1.1badmsgAPI.log, Axis1.1echoAPI.log, Axis1.2badmsgAPI.log, > Axis1.2echoAPI.log > > Arguments and return values of Java type String are incorrectly handled if > they contain non-printing illegal ASCII characters. > Example 1: bad return values: > - - - - - - - - - - - - - - - > E.g. the string > "bad char: " + (char)3 + "." > Trivial example: > foo.jws: > public class foo { > public String badmsg() > { > return "bad: " + (char)3 + "."; > } > } > When calling this method and the server is running on Axis 1.1, it returns > XML with the illegal character ASCII "3" in the text: > <badmsgReturn xsi:type="xsd:string">bad: ?.</badmsgReturn> > This causes an XML parse exception on the client side > ("org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x3) was > found in the element content of the document.") > With Axis 1.2, the server doesn't even return a valid response: I get an HTTP > 200 OK with an empty content, causing a different XML parse error. > Example 2: bad parameter values: > - - - - - - - - - - - - - - - - > A similar problem exists when passing such a string from the the client side. > If I have a method in foo.jws: > public class foo { > public String echo(String s) > { > return s; > } > } > Then if I write an ordinary Java client to call this, and pass it a bad > string as in the beginning of this post, I get an exception thrown while the > call is being composed: > java.lang.IllegalArgumentException: The char '0x3' in 'bad char: ?.' is not a > valid XML character. > This is somewhat absurd: shouldn't the serialization layer be encoding these > illegal XML characters as entity escapes? They're entirely legal in the > current locale (US), and normal Java code handles this character quite > normally. Why should it croak when passed by XML/RPC? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
