[mod_python] Lack of support for subrequests in mod_python?

Richard Barrett r.barrett at openinfo.co.uk
Thu Mar 18 16:24:11 EST 2004

I am new to using mod_python, having some limited familiarity with 
writing Apache modules, and a little puzzled by what appear to be 
omissions from the interface mod_python offers compared with Apache's C 
API and mod_perl. I apologize in advance if the issues have been 
covered in the documentation or on the mod_python list and I missed the 
explanations. If that is the case I woul appreciate a reference to 

First up is the lack of access to running subequests using functions on 
a request to analogues of the ap_sub_req_lookup_uri() and 
ap_sub_req_lookup_file() functions, and their friends such as 
ap_run_sub_req(). If I am correct and these capabilities are indeed 
omitted, is there a good reason for me not to consider producing my own 
fork of mod_python-3.1.3 in order to gain access to the functions from 
my python code?

Second up is a separate query about implementation style for 
input/output filters; a Python output filter implementation I have just 
done bringing the issue to mind. I found that successive calls into my 
output filter function to service a particular request were passed a 
succession of different Python filter objects during the life of 
servicing the particular request. For a proxied request returning 
around 80k bytes of data 3 or 4 different filter objects were passed 
in, with the sum total of data from them being the whole of incoming 
response's body. This contrasts with Apache's C API where the filter 
function would be passed the same context data on each call for 
servicing a given request. The filter I was writing needed state to be 
carried from the inception of the request's processing until the EOS 
bucket was encountered; the filter uses an incremental HTML parser with 
a SAX interface which is being feed data progressively all of which is 
not necessarily consumed during the life of my filter function's 
invocation during which the data was read from the filter object. My 
initial thought was that filter objects should have an attribute, 
initialized to None, which my filter could use to store a state object 
for recovery on each entry to my filter function. With such a state 
variable unavailable, my second thought was to use a global dictionary 
using the filter's id() as key to a state variable as value. But both 
of there were non-starters because filter objects passed into my filter 
function could be different throughout the life of the particular 
filter invocation. I ended using the global dictionary idea but with 
the request and server obeject id()s as key (belt and braces approaches 
possibly). It works but feels a bit inelegant and I am wondering what 
an "expert" would have done to solve the problem.

Anatomically feasible advice on the above topics would be appreciated.

Richard Barrett                               http://www.openinfo.co.uk

More information about the Mod_python mailing list