[mod_python] Lack of support for subrequests in mod_python?

On Thu, 18 Mar 2004, Richard Barrett wrote:

> 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?

They aren't there because noone has needed them so far. Instead producing
a fork, why not subscribe to the python-dev at httpd.apache.org list and
submit a patch?

> 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.

I cc-d the python-dev at httpd list, I think we should move it there since
this is very techical and concerns how mod_python works rather than how to
use it.

Reading the above - it's hard for me to say right off the bat why there is
a new filter object created every time - there may be a good reason for
it, or there may be no good reason at all.

This will definitely need some code studying, which, btw, you're more than
welcome to do. If you need a quick fix - then the filter.req I'm sure is
the same throughout the request, so you can store your data as an
attribute of the request object, rather than filter.

Grisha