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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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.
