[mod_python] onunload ie mod_python

Fair enough; at least the original poster has a couple of options now :)

Nick

Graham Dumpleton wrote:
> 
> On 28/10/2005, at 1:40 AM, Nick wrote:
> 
>> Graham Dumpleton wrote:
>>
>>> On 27/10/2005, at 6:31 AM, Nick wrote:
>>>
>>>> See also  
>>>> http://developer.apple.com/internet/webcontent/xmlhttpreq.html for  
>>>> another solution (there are many resources for this information, but 
>>>> I  like that one best).
>>>>
>>>> SimpleXMLRPCServer is a standard module in Python, and I don't think 
>>>>  it's as complex as you might think, but the above solution might 
>>>> yield  quicker results for you.
>>>
>>> As far as integrating XML-RPC into mod_python, you are possibly better
>>> of using the xmlrpclib.dumps() and xmlrpclib.loads() functions directly.
>>>  From memory this gives better control over handling errors. At least
>>> I know I had a good reason at the time which I can't think of right now.
>>> Possibly because overriding SimpleXmlRpcServer didn't provide a good
>>> way of returning a 404 when function didn't exist.
>>
>>
>> I don't believe you must return a 404 when a function doesn't exist, 
>> but only when a service doesn't exist.  From the spec:
>>
>> "Unless there's a lower-level error, always return 200 OK."
>>
>> A non-existant function would return a fault code.
> 
> 
> One of the problems with the XML-RPC specification is that there is
> no concept of an error origin. All error fault codes fall in the same
> range. The SimpleXMLRPCServer if I recall properly returns a fault
> code of 1 for missing methods or any internal problem it itself may
> have. This is next to useless when you consider that any application
> code usually starts error numbers at 1 as well, one just can't
> distinguish errors very easily. It is thus helpful to at least use
> a distinct error for not being able to map a callable function in
> the first place.
> 
> I can't remember exactly, but there may have been other reasons as
> well. It was all about the time when I found the security hole in the
> SimpleXMLRPCServer implementation so it may have been a general
> distrust of the code. :-)
> 
> Graham