You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2006/05/07 02:31:26 UTC
[jira] Created: (MODPYTHON-170) Allow access to
request_rec/server_rec/conn_rec/filter_rec as Python CObject.
Allow access to request_rec/server_rec/conn_rec/filter_rec as Python CObject.
-----------------------------------------------------------------------------
Key: MODPYTHON-170
URL: http://issues.apache.org/jira/browse/MODPYTHON-170
Project: mod_python
Type: New Feature
Components: core
Reporter: Graham Dumpleton
Assigned to: Graham Dumpleton
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;
request_rec* req;
ssl_is_https_t ssl_is_https = 0;
int result = 0;
if (!PyArg_ParseTuple(args,"O",&req_object))
return 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)
return Py_BuildValue("i",0);
result = ssl_is_https(req->connection);
return Py_BuildValue("i",result);
}
The call to this form Python code would be:
import myextension
def handler(req):
if myextension.is_https(req.request_rec):
...
Note that something like this was posted some time back:
http://www.modpython.org/pipermail/mod_python/2006-February/020340.html
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-170) Allow access to
request_rec/server_rec/conn_rec/filter_rec as Python CObject.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-170?page=all ]
Graham Dumpleton resolved MODPYTHON-170.
----------------------------------------
Resolution: Fixed
> Allow access to request_rec/server_rec/conn_rec/filter_rec as Python CObject.
> -----------------------------------------------------------------------------
>
> Key: MODPYTHON-170
> URL: http://issues.apache.org/jira/browse/MODPYTHON-170
> Project: mod_python
> Issue Type: New Feature
> Components: core
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> 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;
> request_rec* req;
> ssl_is_https_t ssl_is_https = 0;
> int result = 0;
> if (!PyArg_ParseTuple(args,"O",&req_object))
> return 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)
> return Py_BuildValue("i",0);
> result = ssl_is_https(req->connection);
> return Py_BuildValue("i",result);
> }
> The call to this form Python code would be:
> import myextension
> def handler(req):
> if myextension.is_https(req.request_rec):
> ...
> Note that something like this was posted some time back:
> http://www.modpython.org/pipermail/mod_python/2006-February/020340.html
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MODPYTHON-170) Allow access to
request_rec/server_rec/conn_rec/filter_rec as Python CObject.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Graham Dumpleton closed MODPYTHON-170.
--------------------------------------
> Allow access to request_rec/server_rec/conn_rec/filter_rec as Python CObject.
> -----------------------------------------------------------------------------
>
> Key: MODPYTHON-170
> URL: https://issues.apache.org/jira/browse/MODPYTHON-170
> Project: mod_python
> Issue Type: New Feature
> Components: core
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> 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;
> request_rec* req;
> ssl_is_https_t ssl_is_https = 0;
> int result = 0;
> if (!PyArg_ParseTuple(args,"O",&req_object))
> return 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)
> return Py_BuildValue("i",0);
> result = ssl_is_https(req->connection);
> return Py_BuildValue("i",result);
> }
> The call to this form Python code would be:
> import myextension
> def handler(req):
> if myextension.is_https(req.request_rec):
> ...
> Note that something like this was posted some time back:
> http://www.modpython.org/pipermail/mod_python/2006-February/020340.html
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (MODPYTHON-170) Allow access to
request_rec/server_rec/conn_rec/filter_rec as Python CObject.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-170?page=all ]
Work on MODPYTHON-170 started by Graham Dumpleton.
> Allow access to request_rec/server_rec/conn_rec/filter_rec as Python CObject.
> -----------------------------------------------------------------------------
>
> Key: MODPYTHON-170
> URL: http://issues.apache.org/jira/browse/MODPYTHON-170
> Project: mod_python
> Issue Type: New Feature
> Components: core
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> 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;
> request_rec* req;
> ssl_is_https_t ssl_is_https = 0;
> int result = 0;
> if (!PyArg_ParseTuple(args,"O",&req_object))
> return 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)
> return Py_BuildValue("i",0);
> result = ssl_is_https(req->connection);
> return Py_BuildValue("i",result);
> }
> The call to this form Python code would be:
> import myextension
> def handler(req):
> if myextension.is_https(req.request_rec):
> ...
> Note that something like this was posted some time back:
> http://www.modpython.org/pipermail/mod_python/2006-February/020340.html
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MODPYTHON-170) Allow access to
request_rec/server_rec/conn_rec/filter_rec as Python CObject.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-170?page=all ]
Graham Dumpleton updated MODPYTHON-170:
---------------------------------------
Fix Version/s: 3.3
With possible howls of protest, I'm going to add this in for 3.3 except that only doing it for request, server and connection objects. At this point it doesn't make sense to do it for filter objects as how mod_python sets up a bucket brigade probably makes it pointless as that bucket brigade may interfere. I will call the members _request_rec, _server_rec and _conn_rec. The leading underscore is to indicate they are semi private feature and not for normal use.
Sorry, just couldn't resist in putting this in now as have some quite amazing stuff working which requires getting proper access to the underlying Apache structures. I would like other people to be able to experiment with this stuff without hacking mod_python first. :-)
> Allow access to request_rec/server_rec/conn_rec/filter_rec as Python CObject.
> -----------------------------------------------------------------------------
>
> Key: MODPYTHON-170
> URL: http://issues.apache.org/jira/browse/MODPYTHON-170
> Project: mod_python
> Issue Type: New Feature
> Components: core
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> 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;
> request_rec* req;
> ssl_is_https_t ssl_is_https = 0;
> int result = 0;
> if (!PyArg_ParseTuple(args,"O",&req_object))
> return 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)
> return Py_BuildValue("i",0);
> result = ssl_is_https(req->connection);
> return Py_BuildValue("i",result);
> }
> The call to this form Python code would be:
> import myextension
> def handler(req):
> if myextension.is_https(req.request_rec):
> ...
> Note that something like this was posted some time back:
> http://www.modpython.org/pipermail/mod_python/2006-February/020340.html
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira