Turning off xmlrpc handling
ZPublisher seems to assume that if the Content-type on an HTTP POST is "text/xml", then the request contains an xmlrpc call. I would like to POST an XML document and handle it myself in an External Method (via REQUEST.BODY), but ZPublisher exits with an error when it tries to parse the XML message looking for a proper rpc call. Can anyone think of an elegant way to tell Zope *not* to do this? 1. I would prefer not to hack Zope. 2. I cannot change the Content-type on the client 3. I apparently cannot use apache mod_rewrite to rewrite headers. Thanks in advance, John Ziniti
John Ziniti wrote:
ZPublisher seems to assume that if the Content-type on an HTTP POST is "text/xml", then the request contains an xmlrpc call.
I would like to POST an XML document and handle it myself
1. I would prefer not to hack Zope.
The more I look at this problem and the Zope code set up to handle it, the more I think that hacking Zope is the only way to accomplish what I want. The question I keep coming to, though, is "Is it right that Zope assumes that all POSTs with a text/xml payload are xmlrpc calls?" and I can't help but answering "no". Couldn't we change Zope so that you have to specifically indicate an xmlrpc call with a Content-type that would not be used for something else, like "application/xmlrpc"? Or is inventing new Content-types considered bad form? JZ
John Ziniti wrote:
ZPublisher seems to assume that if the Content-type on an HTTP POST is "text/xml", then the request contains an xmlrpc call.
I would like to POST an XML document and handle it myself
1. I would prefer not to hack Zope.
The more I look at this problem and the Zope code set up to handle it, the more I think that hacking Zope is the only way to accomplish what I want. The question I keep coming to, though, is "Is it right that Zope assumes that all POSTs with a text/xml payload are xmlrpc calls?" and I can't help but answering "no".
And you are correct ;) Unfortunately, though, this misfeature has been around for a long time and would break a lot of people if the default were changed. That doesn't mean it shouldn't necessarily be changed anyway, possibly with some sort of backward-compatibility mode that would make the transition reasonable. Short of that though, its your lucky day, since I happen to have an add-on product laying around that does exactly what you want ;) The attached XmlFix product disables xml-rpc handling w/o having to hack Zope (well, it hacks it from the outside, at least), which lets you handle xml sent via POST. This is based on a SoapFix product that does much the same thing, except that it is more discriminating and only lets SOAP requests bypass the xml-rpc handling (which otherwise works normally). I've attached that as well, in case it is useful to anybody. Hope this helps! Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
The more I look at this problem and the Zope code set up to handle it, the more I think that hacking Zope is the only way to accomplish what I want. The question I keep coming to, though, is "Is it right that Zope assumes that all POSTs with a text/xml payload are xmlrpc calls?" and I can't help but answering "no".
And you are correct ;) Unfortunately, though, this misfeature has been around for a long time and would break a lot of people if the default were changed. That doesn't mean it shouldn't necessarily be changed anyway, possibly with some sort of backward-compatibility mode that would make the transition reasonable.
This sounds to me like it won't be getting changed any time soon. :-)
Short of that though, its your lucky day, since I happen to have an add-on product laying around that does exactly what you want ;)
The attached XmlFix product disables xml-rpc handling w/o having to hack Zope (well, it hacks it from the outside, at least), which lets you handle xml sent via POST.
Thanks, Brian. That's a nifty piece of code -- I never realized that you could do something like this in a Product; but it makes sense now that I see it (wooo Python!). The Product version is definitely more supportable and upgrade- proof than hacking the Zope code itself. JZ
participants (2)
-
Brian Lloyd -
John Ziniti