You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by bu...@apache.org on 2002/10/01 09:55:28 UTC

DO NOT REPLY [Bug 13168] New: - Unexpected XML parser behavior

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13168>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13168

Unexpected XML parser behavior

           Summary: Unexpected XML parser behavior
           Product: XML-RPC
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Source
        AssignedTo: rpc-dev@xml.apache.org
        ReportedBy: p.maseres@wanadoo.fr


When bad requests are addressed to the XmlRpcServer, the XML parser produces 
strange results.

Case 1
------
The client sends a wellformed XML request which content is not a correct XML-
RPC call.
The parser seems not to detect the error, and the XmlRpcHandler is called back 
with data retained from a previous successful invocation (method name). When 
this error occurs in the first request processing, the handler is called with a 
null reference... This seems to be a bad data state management in the server's 
shared workers.

Sample client code :

    URL url = new URL(endpoint);
    HttpURLConnection http = (HttpURLConnection) url.openConnection();
    http.setRequestMethod("POST");
    http.setDoOutput(true);
    PrintWriter pw = new PrintWriter(http.getOutputStream());
    pw.print("<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>");
    pw.print("<a>hello</a>");
    pw.flush();

Case 2
------
The client request content is not XML at all.
The parser detects the invalid format, and sends back an XML-RPC fault 
reporting the SAX exception.

Sample client code :

    URL url = new URL(endpoint);
    HttpURLConnection http = (HttpURLConnection) url.openConnection();
    http.setRequestMethod("POST");
    http.setDoOutput(true);
    PrintWriter pw = new PrintWriter(http.getOutputStream());
    pw.print("Bye");
    pw.flush();

I think these two cases should be handled both as a same invalid invocation. 
The client seems not to use the XML-RPC protocol, for instance because of a bad 
url configuration, and i'm not sure answering an XML-RPC fault is the best way. 
I'd prefer the XmlRpcServer to throw a specific java exception, and thus give 
the main program (in our case, servlets) a chance to handle the error at the 
lower HTTP level. In deed, any IO exception during the XML/XML-RPC parsing 
could also be processed this way.

Re: DO NOT REPLY [Bug 13168] New: - Unexpected XML parser behavior

Posted by John Wilson <tu...@wilson.co.uk>.
[snip]

It would have been better to submit this as two bug reports.

> When bad requests are addressed to the XmlRpcServer, the XML parser
> produces strange results.
>
> Case 1
> ------
> The client sends a wellformed XML request which content is not a
> correct XML- RPC call.
> The parser seems not to detect the error, and the XmlRpcHandler is
> called back with data retained from a previous successful invocation
> (method name). When this error occurs in the first request
> processing, the handler is called with a null reference... This seems
> to be a bad data state management in the server's shared workers.
>
> Sample client code :
>
>     URL url = new URL(endpoint);
>     HttpURLConnection http = (HttpURLConnection) url.openConnection();
>     http.setRequestMethod("POST");
>     http.setDoOutput(true);
>     PrintWriter pw = new PrintWriter(http.getOutputStream());
>     pw.print("<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>");
>     pw.print("<a>hello</a>");
>     pw.flush();
>

This seems a genuine bug in the server - it's almost certainly not a Parser
bug.

> Case 2
> ------
> The client request content is not XML at all.
> The parser detects the invalid format, and sends back an XML-RPC fault
> reporting the SAX exception.
>
> Sample client code :
>
>     URL url = new URL(endpoint);
>     HttpURLConnection http = (HttpURLConnection) url.openConnection();
>     http.setRequestMethod("POST");
>     http.setDoOutput(true);
>     PrintWriter pw = new PrintWriter(http.getOutputStream());
>     pw.print("Bye");
>     pw.flush();
>

This is expected behaviour and is, in my view, correct.





Re: DO NOT REPLY [Bug 13168] New: - Unexpected XML parser behavior

Posted by John Wilson <tu...@wilson.co.uk>.
[snip]

It would have been better to submit this as two bug reports.

> When bad requests are addressed to the XmlRpcServer, the XML parser
> produces strange results.
>
> Case 1
> ------
> The client sends a wellformed XML request which content is not a
> correct XML- RPC call.
> The parser seems not to detect the error, and the XmlRpcHandler is
> called back with data retained from a previous successful invocation
> (method name). When this error occurs in the first request
> processing, the handler is called with a null reference... This seems
> to be a bad data state management in the server's shared workers.
>
> Sample client code :
>
>     URL url = new URL(endpoint);
>     HttpURLConnection http = (HttpURLConnection) url.openConnection();
>     http.setRequestMethod("POST");
>     http.setDoOutput(true);
>     PrintWriter pw = new PrintWriter(http.getOutputStream());
>     pw.print("<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>");
>     pw.print("<a>hello</a>");
>     pw.flush();
>

This seems a genuine bug in the server - it's almost certainly not a Parser
bug.

> Case 2
> ------
> The client request content is not XML at all.
> The parser detects the invalid format, and sends back an XML-RPC fault
> reporting the SAX exception.
>
> Sample client code :
>
>     URL url = new URL(endpoint);
>     HttpURLConnection http = (HttpURLConnection) url.openConnection();
>     http.setRequestMethod("POST");
>     http.setDoOutput(true);
>     PrintWriter pw = new PrintWriter(http.getOutputStream());
>     pw.print("Bye");
>     pw.flush();
>

This is expected behaviour and is, in my view, correct.