[XMLRPC-159] HTTP status codes are not checked

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.1, 3.1.1
• Fix Version/s: 3.1.2
• Assignee: Jochen Wiedmann
• Reporter: Brandon DuRette
• Created: 01/Oct/08 23:02
• Updated: 29/Apr/09 20:03
• Resolved: 28/Nov/08 21:37

Description

When executing XMLRPC requests over HTTP using the Commons or Sun transports, the HTTP status codes are not checked before the response is parsed. Because of this, the underlying connectivity issue is masked from the caller, who want to do something more user friendly based on the underlying status. Instead, a more generic exception is thrown, typically in the parser.

For example, if for some reason I point my client at a server other than the one that is correctly configured to respond to XMLRPC requests and it responds with a 404 and a 404 error page, the XML parser throws an exception:

Caused by: org.apache.xmlrpc.client.XmlRpcClientException: Failed to parse servers response: Expected methodResponse ele
ment, got html
at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse(XmlRpcStreamTransport.java:177)
at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:145)
at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTransport.java:94)
at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:53)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:166)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:157)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:146)
at com.smartbear.ccollab.datamodel.xmlrpc.XmlRpcClientEngineImplementation$1.invoke(XmlRpcClientEngineImplementa
tion.java:144)
... 16 more
Caused by: org.xml.sax.SAXParseException: Expected methodResponse element, got html
at org.apache.xmlrpc.parser.XmlRpcResponseParser.startElement(XmlRpcResponseParser.java:98)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(Unknown
Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Sou
rce)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)

The same would happen for other error pages.

Proposal:

Create a subclass of XmlRpcException called XmlRpcHttpTransportException that is thrown by the HTTP transports when the server does not respond with a 200 status code. The exception should carry with it the status code from the server, so that clients can handle them appropriately.

Patch:

I have working code for this, but want to do some further testing before attaching the patch.