Re: [Twisted-Python] Problem with XMLRPC resource wrapped with guard basic auth
I was indeed being tricked. I actually tested soap with a real client, but with xmlrpc i was using the browser. I was expecting to see the same error message, and instead got a new one that was presented by the modifications I pulled out of the trunk to support the issue in #4014. I was expecting to see the older error message and it was replaced. A quick test via,
import xmlrpclib server = xmlrpclib.Server('http://user:password@localhost:9999/rpc2') server.quote()
Showed it indeed worked like it should. Swapped it to use SSL and now I'm
all set.
Thank you for the clarification. Next time I'll test more before posting to
the list. ;)
TWKiel
----------------------------------------
From: exarkun@twistedmatrix.com
Sent: Tuesday, October 06, 2009 6:43 PM
To: asset@impactdamage.com, "Twisted general discussion"
Using the current trunk r27366 (which is after #4014 fixed a related issue), I am having trouble with an implementation of web.guard wrapped XMLRPC. This is a new test implementation to expose both a soap and xmlrpc interface. SOAP works, but xmlrpc throws UnsupportedMethod POST.
I think you're being tricked by the confusing way in which this exception is displayed and by a slight implementation difference (and indeed externally visible behavioral difference) between XMLRPC and SOAPPublisher. SOAPPublisher defines "render" and no other render methods. So it will accept any request method and treat it the same way. It will never raise UnsupportedMethod. XMLRPC, on the other hand, defines "render_POST" and no other render methods, so it will only accept POST requests. For any other request, it will raise UnsupportedMethod and create that exception with a tuple of which methods it does allow. ('POST',) in this case. The exception I see when I approach this server at /rpc2 with my web browser (which is the only thing I've tried, because it's too much work to put together a real xml-rpc client that supports basic auth) is just what I'd expect. The browser issues a GET, the XMLRPC resource rejects this, indicating it only accepts POSTs. It may be worth improving the way UnsupportedMethod exceptions are stringified to make it more clear what's going on. Or, if this doesn't actually explain your problem, feel free to point that out and provide more details about how the client you're using behaves. Jean-Paul
participants (1)
-
asset