| Graham Dumpleton 2006-01-31, 2:45 am |
| An initial few comments from a first pass through.
def _write(self, request, response, content_type='text/xml'):
request.send_http_header()
request.content_type = content_type
request.write(response)
This is technically wrong, although it doesn't matter on mod_python > 3.0.
The issue is that send_http_header() in mod_python 2.7 should only be
called after content type is set. Here they do it before. Only works because
in 3.X send_http_header() is a NOP.
# men have been killed for less
temp = sys.stderr
sys.stderr = stderr_mod_python(self.request)
...
sys.stderr = temp
This is not safe in a multithread MPM.
except Exception, e:
# report exception back to server
response = xmlrpclib.dumps(
xmlrpclib.Fault(1, "%s:%s" % (sys.exc_type, sys.exc_value))
)
# and also log it, duh
etype, evalue, etb = sys.exc_info()
stack = traceback.format_exception(etype, evalue, etb)
for l in stack:
sys.stderr.write(l)
First it uses fudged sys.stderr. Second is that it exacerbates a problem in
XML-RPC which is that there is no concept of namespaces for error return
codes. Because they have used arbitrary return status of "1" for internal
exception or unexpected exception in user code, then you can't distinguish
easily a valid fault response with return status of "1" generated by user
code from unexpected exception.
It may be more appropriate to generate a 500 HTTP error response in
this circumstance given that it really consitutes an internal server error
rather than it being a valid XML-RPC fault response generated by the
user. This is an issue for debate though. It depends on whether you want
to be conformant with how SimpleXmlRpcServer works which is where
this questionable code came from in the first place.
Other issues are that it doesn't check incoming content type to validate
that it is actually 'text/xml' per specification for XML-RPC. It doesn't use
incoming content length for read on POST data which can be a problem
in some cases. It also doesn't set outgoing content length as per
specification for XML-RPC. It could also perhaps be a bit more knowledgeable
about mod_python and pass through apache.SERVER_RETURN exception
so as to allow exposed methods to still generate it if need be.
This isn't the only implementation of XML-RPC support integrated with
mod_python. I have an alternate take on it in Vampire which isn't bound
to the SimpleXmlRpcServer base class. See:
http://svn.dscpl.com.au/vampire/tru...mpire/xmlrpc.py
I can't find the others right now, but I have posted links to them before
on the main mod_python list.
Overall, I'm not sure at this point that it is worthwhile putting XML-
RPC support in mod_python. If it is done, I would prefer to see it be
done as part of a larger effort to provide a range of handler components
which all work consistently together, rather than adhoc bits and pieces
that cannot be glued together easily.
Grisha wrote ..[vbcol=seagreen]
>
> If someone here has spare Brain/CPU cycles, could you look at the attached
> code and provide feedback?
>
> Grisha
>
> ---------- Forwarded message ----------
> Date: Mon, 30 Jan 2006 18:04:42 -0800
> From: Matt Chisholm <matt@bittorrent.com>
> Subject: Re: contribution to mod_python: Apache + SimpleXMLRPCServer
>
> On Jan 30 2006, 11:42, Matt Chisholm wrote:
|