Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <894612185.1119912957741.JavaMail.jira@ajax.apache.org>
Date: Tue, 28 Jun 2005 00:55:57 +0200 (CEST)
From: "Shankar Unni (JIRA)" <axis-dev@ws.apache.org>
To: axis-dev@ws.apache.org
Subject: [jira] Commented: (AXIS-2025) Illegal XML characters in String
 arguments and return values cause XML exceptions in Axis calls
In-Reply-To: <1080084914.1117343753349.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/AXIS-2025?page=comments#action_12314562 ] 

Shankar Unni commented on AXIS-2025:
------------------------------------

As far as I can tell, all that is required is for strings to be scanned by the encoder for the presence of illegal XML characters, and have them be replaced by entity escapes.

I presume someone's doing this for characters like "<", right? You don't just dump the "<" as is to the XML output as TEXT - you do an HTML escape or something to handle this, don't you?

What's the difference between passing a "<" and passing a "0x3" inside a string? Both are legal String characters. Why does Axis make no attempt for one, but handle the other?

If this is something that the XML RPC standards rule on, I'd like to see this. Do the XML RPC standards say "this is a string type; you can only pass Strings that contain printable ascii characters"? That would be a strange "RPC" standard, indeed..


> 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