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')
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. ;)
Sent: Tuesday, October 06, 2009 6:43 PM
To: firstname.lastname@example.org, "Twisted general discussion" <email@example.com>
Subject: Re: [Twisted-Python] Problem with XMLRPC resource wrapped with guard basic auth
On 12:00 am, firstname.lastname@example.org wrote:
>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
>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 defines "render" and no other render methods. So it will
accept any request method and treat it the same way. It will never
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.