At the moment, if mod_python doesn't expose a feature of Apache that you may want to use, you are stuffed and either have to convince mod_python maintainers to add it, patch your mod_python or create a Python loadable module that builds against both mod_python headers and Apache headers.
In the latter, it needs access to mod_python headers so as to be able to look inside the mod_python requestobject to get at the request_rec Apache structure. In practice, the only thing from the mod_python requestobject that such a extension module is going to want, is the request_rec structure, thus it is probably simpler and makes building such an extension easier, if the mod_python requestobject provided a "request_rec" attribute which was a Python CObject wrapper which wrapped the C request_rec pointer. Similarly, access to server_rec/conn_rec/filter_rec could also be provided.
For example, you might have a C extension function like:
typedef int (ssl_is_https_t)(conn_rec);
static PyObject* is_https(PyObject* module, PyObject* args)
PyObject* req_object = 0;
ssl_is_https_t ssl_is_https = 0;
int result = 0;
if (! PyCObject_Check(req_object))
PyErr_SetString(PyExc_TypeError,"not a CObject");
req = PyCObject_AsVoidPtr(req_object);
ssl_is_https = (ssl_is_https_t)apr_dynamic_fn_retrieve("ssl_is_https");
if (ssl_is_https == 0)
result = ssl_is_https(req->connection);
The call to this form Python code would be:
Note that something like this was posted some time back:
but the problem with it was that it needed the mod_python header files when compiling. Using the Python CObject avoids that. Any Python distutils setup.py file still needs to know where the Apache header files etc are, but it can use apxs to get that.