Ticket #533 (defect)

Do you have any references to implementations or discussion which returns 200? The spec says, "Unless there's a lower-level error, always return 200 OK." My interpretation of that is that HTTP is the "lower level", and a 404 is appropriate.

cafeconcleche agrees: http://www.cafeconleche.org/books/xmljava/chapters/ch02s05.html#d0e3484

Python's xmlrpclib has ProtocolError? objects separate from Faults to handle this: http://docs.python.org/lib/protocol-error-objects.html

and Zope has a ticket proposing the exact opposite of what you propose: http://www.zope.org/Collectors/Zope/1175

This has come up before - I think Sylvain and I had this discussion a while back on IRC. My thoughts were along the lines of jfunk's.

Since an XML-RPC request is an HTTP POST to a resource, with the requested method as part of the POST body, I think that jfunk is right that a 404 should not be returned.

Take the following CP 2.2.1 example:

import cherrypy

class RPC2(object):
    def double(self, string):
        return string * 2
    double.exposed = True

cherrypy.tree.mount(RPC2(), '/rpc2')

cherrypy.config.update({'/rpc2':{'xmlrpc_filter.on':True}})

cherrypy.server.start()

Any XML-RPC client would not POST the request to /rpc2/double or /rpc2/triple, but simply to /rpc2. Once the HTTP POST is passed to /rpc2, it is all XML-RPC's game from there on out. It grabs the method from the POST body and tries to find and execute it. Thus, if I request the nonexistant method 'triple', I believe CP should return a 200 and raise an XML-RPC fault, as the HTTP entity that received the POST (/rpc2) exists, but the XML-RPC method does not.

Now, if my XML-RPC client calls the method 'double' from resource /foo, then a 404 is appropriate, as that resource does not exist.

If you are looking for a reference, check out the stdlib !SimpleXMLRPCServer. It returns a 200 and raises a fault for method not found.

That's my story ;-)

Any other thoughts on this? If there are no objections, I will implement this in the trunk and backport it to the 2.2.x line.

I think your take is fine: if the resource (given in the URL) is not found, raise 404, but if the rpcmethod given in the request body is not found, raise a Fault and return 200.

This should be easy to do for CP 3: in the XMLRPCController, change the subhandler lookups to raise a Fault instead of 404.

Getting that to work in CP 2.2 will require changing CP 2.2 too much, I think. I personally don't mind if it isn't fixed there.

Fixed for CP3 in [1172]. I'll see if it is at all possible to fix this for the 2.2.x line...

Any progress on this? Or should we just close it?

Fixed in CP3, but couldn't find a proper way to do it in 2.2.x.

2.x fix in [1503].