[jira] Commented: (MODPYTHON-28) Add a standard test handler in the distribution
[
http://issues.apache.org/jira/browse/MODPYTHON-28?page=comments#action_66505 ]
Jim Gallacher commented on MODPYTHON-28:
You got the LaTex mostly right. There is one error (a stray backslash) which
I've corrected in the attached patch.
As for the testing documentation itself, in section 2.4 item 7 you mention the
need to use a higher level handler such as mod_python publisher (see 3.1),
mpservlets or Vampire. It may not be obvious to the reader that mpservlets and
Vampire are not included with mod_python.
Maybe add somthing at the end of section 2.4 such:
\begin{seealso}
\seeurl{http://home.comcast.net/~d.popowich/mpservlets}{mpservlets}
\seeurl{http://www.dscpl.com.au/projects/vampire}{Vampire}
\end{seealso}
Add a standard test handler in the distribution
---
Key: MODPYTHON-28
URL: http://issues.apache.org/jira/browse/MODPYTHON-28
Project: mod_python
Type: Improvement
Versions: 3.1.4, 2.7.10
Reporter: Nicolas Lehuen
Assignee: Nicolas Lehuen
Fix For: 3.2.0
Attachments: modpython2.tex-jg20050528-1.diff
Improving the testing phase of the installation is crucial as we get a steady
stream of question from new users who can't run the mptest or are confused
about its meaning (for example, the fact that any URL ending with .py runs
the mptest handler is misleading at first).
We should include a standard mptest handler in the distribution so that we
can better help beginners, without making them struggle with a new file
PYTHONPATH, syntax errors in the handler, etc. Ideally, the mptest handler
should display useful informations both in the Apache log and in the result
page ; this would help us check their environment and provide better help.
The information displayed could be (both in the log and the result page) :
- Apache version (+MPM type if this information can be queried at runtime)
- Python version
- mod_python version
- sys.path
- mod_python.publisher available yes/no
- mod_python.psp available yes/no
Of course, if anything goes wrong, it should be clearly stated in the Apache
log (no misleading 404 errors, please !).
The testing phase of the installation would then be : 1) set SetHandler
mod_python.mptest directive and 2) watch the results. This would be far less
messy as it is currently.
--
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-58) _apache._global_lock results in segfault when index number of mutexes
[ http://issues.apache.org/jira/browse/MODPYTHON-58?page=all ]
Jim Gallacher updated MODPYTHON-58:
---
Description:
All of the following calls will cause a segfault when the index is greater than
the number of global mutexes available or index -1.
eg. 32 mutexes created on apache startup
index = 100
_apache._global_lock(req.server, None, index)
_global_unlock(req.server, None, index)
_apache._global_trylock(req.server, None, index)
For all of the corresponding functions in _apachemodule.c, the value of index
is not checked before using it to access the contents of the global array of
mutex locks.
eg.
rv = apr_global_mutex_lock(glb-g_locks[index]);
I'll attach a patch for all three functions that does this check.
eg.
if ((index = (glb-nlocks)) || (index -1)) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
Index %d is out of range for number of global mutex
locks, index);
PyErr_SetString(PyExc_ValueError,
Lock index is out of range for number of global mutex
locks);
return NULL;
}
was:
All of the following calls will cause a segfault when the index is greater than
the number of global mutexes available or index -1.
eg. 32 mutexes created on apache startup
index = 100
_apache._global_lock(req.server, None, index)
_global_unlock(req.server, None, index)
_apache._global_trylock(req.server, None, index)
For all of the corresponding functions in _apachemodule.c, the value of index
is not checked before using it to access the contents of the global array of
mutex locks.
eg.
rv = apr_global_mutex_lock(glb-g_locks[index]);
I'll attach a patch for all three functions that does this check.
eg.
if ((index (glb-nlocks)) || (index -1)) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
Index %d is out of range for number of global mutex
locks, index);
PyErr_SetString(PyExc_ValueError,
Lock index is out of range for number of global mutex
locks);
return NULL;
}
Stupid off by one error in the example.
_apache._global_lock results in segfault when index number of mutexes
---
Key: MODPYTHON-58
URL: http://issues.apache.org/jira/browse/MODPYTHON-58
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4, 3.1.3, 3.2.0
Environment: All
Reporter: Jim Gallacher
Priority: Minor
Attachments: apachemodule.c-jg20050601-1.diff
All of the following calls will cause a segfault when the index is greater
than the number of global mutexes available or index -1.
eg. 32 mutexes created on apache startup
index = 100
_apache._global_lock(req.server, None, index)
_global_unlock(req.server, None, index)
_apache._global_trylock(req.server, None, index)
For all of the corresponding functions in _apachemodule.c, the value of index
is not checked before using it to access the contents of the global array of
mutex locks.
eg.
rv = apr_global_mutex_lock(glb-g_locks[index]);
I'll attach a patch for all three functions that does this check.
eg.
if ((index = (glb-nlocks)) || (index -1)) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
Index %d is out of range for number of global mutex
locks, index);
PyErr_SetString(PyExc_ValueError,
Lock index is out of range for number of global
mutex locks);
return NULL;
}
--
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-59) Add get_session() method to request object
[ http://issues.apache.org/jira/browse/MODPYTHON-59?page=all ] Jim Gallacher updated MODPYTHON-59: --- Version: 3.3.0 (was: 3.2.0) Defering implentation to 3.3. Add get_session() method to request object -- Key: MODPYTHON-59 URL: http://issues.apache.org/jira/browse/MODPYTHON-59 Project: mod_python Type: New Feature Components: core Versions: 3.3.0 Environment: All Reporter: Jim Gallacher Users will get session instances by calling req.get_session(). If a session already exists it will be returned, otherwise a new session instance will be created. Session configuration will be handled using apache directives rather than within their code. Using this scheme means only one session instance will be created per request, which will eliminate the deadlock problems many people experience. Also, using this scheme makes it possible for sessions to be properly handled within psp pages and across req.internal_redirect() calls. Code will be commited to svn shortly. -- 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] Commented: (MODPYTHON-71) Support the HEAD method properly
[
http://issues.apache.org/jira/browse/MODPYTHON-71?page=comments#action_12318388
]
Jim Gallacher commented on MODPYTHON-71:
Apache may already be doing the right thing for us. Using netcat as the client
I ran the some tests using the the following as the handler:
/mp/mptest.py
from mod_python import Session
def handler(req):
req.content_type = 'text/plain'
sess = Session.Session(req)
sess.do_cleanup()
try:
sess['hits'] += 1
except:
sess['hits'] = 0
req.write('mptest.py\n')
req.write('hits: %d\n' % (sess['hits']))
req.write('Blah blah blah blah blah\n')
sess.save()
return apache.OK
Note that the host name has been obscured in these tests.
Test 1.
===
Request
---
GET /mp/mptest.py HTTP/1.1
Host: example.com
Connection: close
Response
HTTP/1.1 200 OK
Date: Wed, 10 Aug 2005 18:58:49 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.2.0-dev-20050809
Python/2.3.5
Cache-Control: no-cache=set-cookie
Set-Cookie: pysid=0a81c130420c736c10e196e48603cb96; path=/mp
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain
a
mptest.py
8
hits: 0
19
Blah blah blah blah blah
0
Comments
Netcat just dumps out whatever it receives. The stray a, 8, 19 and 0 are part
of the chunked transfer scheme and can be ignored.
Test 2.
===
Request
---
HEAD /mp/mptest.py HTTP/1.1
Host: example.com
Connection: close
Response
HTTP/1.1 200 OK
Date: Wed, 10 Aug 2005 18:59:04 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.2.0-dev-20050809
Python/2.3.5
Cache-Control: no-cache=set-cookie
Set-Cookie: pysid=2cc812f1426e5580aaf86904ee41fa3d; path=/mp
Connection: close
Content-Type: text/plain
Comments
Looks like mod_python is doing the right thing. The body of the request is not
being sent to the client.
As long as any publisher methods we create stuff HEAD into the allowed methods
we should be ok wrt the RFC. I'd say that the change Nicolas made in
publisher.py is correct, although
if req.method!='HEAD':
req.write(result)
may not be required if the apache ap_rwrite() call is taking care of it. I'll
dig into the apache code later tonight to confirm this.
Support the HEAD method properly
Key: MODPYTHON-71
URL: http://issues.apache.org/jira/browse/MODPYTHON-71
Project: mod_python
Type: Bug
Versions: 3.1.3, 2.7.10, 3.2.0, 3.1.4
Reporter: Nicolas Lehuen
Priority: Minor
RFC 2616, 9.4 HEAD :
8---8---8---8---8---
The HEAD method is identical to GET except that the server MUST NOT return
a message-body in the response. The metainformation contained in the HTTP
headers in response to a HEAD request SHOULD be identical to the
information sent in response to a GET request.
8---8---8---8---8---
Could we make sure that nothing is returned to the client ? Perhaps by making
sure that req.write does nothing whenever the request method is HEAD ?
--
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] Commented: (MODPYTHON-72) mod_python.publisher no longer pays attention to result of req.get_addhandler_exts()
[ http://issues.apache.org/jira/browse/MODPYTHON-72?page=comments#action_12320155 ] Jim Gallacher commented on MODPYTHON-72: I can't reproduce this problem, or maybe I don't understand it properly. In the example, is # page.py a typo and should actually be page.html? ie. # page.html def index(): return html/bodypXXX/p/body/html works fine for me. Likewise if I have a file stuff.html: # stuff.html def index(req): return html/bodypMODPYTHON-72 stuff/p/body/html calling either /stuff or /stuff.html returns the correct page. mod_python.publisher no longer pays attention to result of req.get_addhandler_exts() Key: MODPYTHON-72 URL: http://issues.apache.org/jira/browse/MODPYTHON-72 Project: mod_python Type: Bug Versions: 3.2.0 Reporter: Nicolas Lehuen Assignee: Nicolas Lehuen Says Graham : A final issue, is that latest mod_python.publisher no longer pays attention to result of req.get_addhandler_exts(). This means that where you used to be able to say: # .htaccess AddHandler mod_python .html PythonHandler mod_python.publisher # page.py def index(): return html/bodypXXX/p/body/html with URL of /page.html, this no longer appears to work for me. In short it appears that one can only use .py as an extension or no extension at all. Defining another extension to AddHandler or PythonHandler seems to have no effect. -- 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] Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[
http://issues.apache.org/jira/browse/MODPYTHON-77?page=comments#action_12320905
]
Jim Gallacher commented on MODPYTHON-77:
I tried your patch and the unit tests fail. Apache fails to start, with the
following message in the error log:
Fatal Python error: PyThreadState_Get: no current thread
Using
GCC 4.0.2
apache mpm-prefork 2.0.54
python 2.3.5
Also, please submit your patches as unified diffs (diff -u) or even better if
you are using code checked out of subversion use svn diff
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3
--
Key: MODPYTHON-77
URL: http://issues.apache.org/jira/browse/MODPYTHON-77
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4
Environment: Python = 2.3
Reporter: Boyan Boyadjiev
Attachments: diff.txt, mod_python.c
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3 because of the PEP 311 (Simplified Global
Interpreter Lock Acquisition for Extensions):
...
Limitations and Exclusions
This proposal identifies a solution for extension authors with
complex multi-threaded requirements, but that only require a
single PyInterpreterState. There is no attempt to cater for
extensions that require multiple interpreter states. At the time
of writing, no extension has been identified that requires
multiple PyInterpreterStates, and indeed it is not clear if that
facility works correctly in Python itself.
...
For mod_python this means, that complex Python extensions won't work any more
with Python = 2.3, because they are supposed to work only with the first
interpreter state initialized for the current process (a problem we
experienced). The first interpreter state is not used by mod_python after the
python_init is called.
One solution, which works fine for me, is to save the first interpreter state
into the interpreters dictionary in the function python_init
(MAIN_INTERPRETER is used as a key):
static int python_init(apr_pool_t *p, apr_pool_t *ptemp,
apr_pool_t *plog, server_rec *s)
{
...
/* initialize global Python interpreter if necessary */
if (! Py_IsInitialized())
{
/* initialze the interpreter */
Py_Initialize();
#ifdef WITH_THREAD
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, s,
python_init: PyDict_New() failed! No more memory?);
exit(1);
}
{
/*
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
BEGIN
*/
PyObject *p = 0;
interpreterdata * idata = (interpreterdata
*)malloc(sizeof(interpreterdata));
PyThreadState* currentThreadState = PyThreadState_Get();
PyInterpreterState *istate = currentThreadState-interp;
idata-istate = istate;
/* obcallback will be created on first use */
idata-obcallback = NULL;
p = PyCObject_FromVoidPtr((void ) idata, NULL); /*p-refcout = 1*/
PyDict_SetItemString(interpreters, MAIN_INTERPRETER, p);
/*p-refcout = 2*/
Py_DECREF(p); /*p-refcout = 1*/
/*
END
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
*/
}
/* Release the thread state because we will never use
* the main interpreter, only sub interpreters created later. */
PyThreadState_Swap(NULL);
#ifdef WITH_THREAD
/* release the lock; now other threads can run */
PyEval_ReleaseLock();
#endif
}
return OK;
}
Another change I've made in the attached file is to Py_DECREF(p) in
get_interpreter, which will remove leaky reference to the PyCObject with the
interpreter data. This was not a real problem, but now I see fewer leaks in
BoundsChecker :-).
--
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] Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[
http://issues.apache.org/jira/browse/MODPYTHON-77?page=comments#action_12320924
]
Jim Gallacher commented on MODPYTHON-77:
-1 for me. Unit tests fail for diff3.txt.
For some reason 1 hunk is rejected when diff3 is applied against svn/trunk.
Manually removing PyThreadState_Swap as suggested by Boyan does not help. It
seems like apache is segfaulting. The only thing in the error log is the
following:
[Fri Sep 02 14:31:04 2005] [notice] mod_python: Creating 8 session mutexes
based on 256 max processes and 0 max threads.
at which point the apache process dies.
Which mpm are you using, Boyan?
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3
--
Key: MODPYTHON-77
URL: http://issues.apache.org/jira/browse/MODPYTHON-77
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4
Environment: Python = 2.3
Reporter: Boyan Boyadjiev
Attachments: diff.txt, diff2.txt, diff3.txt, mod_python.c
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3 because of the PEP 311 (Simplified Global
Interpreter Lock Acquisition for Extensions):
...
Limitations and Exclusions
This proposal identifies a solution for extension authors with
complex multi-threaded requirements, but that only require a
single PyInterpreterState. There is no attempt to cater for
extensions that require multiple interpreter states. At the time
of writing, no extension has been identified that requires
multiple PyInterpreterStates, and indeed it is not clear if that
facility works correctly in Python itself.
...
For mod_python this means, that complex Python extensions won't work any more
with Python = 2.3, because they are supposed to work only with the first
interpreter state initialized for the current process (a problem we
experienced). The first interpreter state is not used by mod_python after the
python_init is called.
One solution, which works fine for me, is to save the first interpreter state
into the interpreters dictionary in the function python_init
(MAIN_INTERPRETER is used as a key):
static int python_init(apr_pool_t *p, apr_pool_t *ptemp,
apr_pool_t *plog, server_rec *s)
{
...
/* initialize global Python interpreter if necessary */
if (! Py_IsInitialized())
{
/* initialze the interpreter */
Py_Initialize();
#ifdef WITH_THREAD
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, s,
python_init: PyDict_New() failed! No more memory?);
exit(1);
}
{
/*
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
BEGIN
*/
PyObject *p = 0;
interpreterdata * idata = (interpreterdata
*)malloc(sizeof(interpreterdata));
PyThreadState* currentThreadState = PyThreadState_Get();
PyInterpreterState *istate = currentThreadState-interp;
idata-istate = istate;
/* obcallback will be created on first use */
idata-obcallback = NULL;
p = PyCObject_FromVoidPtr((void ) idata, NULL); /*p-refcout = 1*/
PyDict_SetItemString(interpreters, MAIN_INTERPRETER, p);
/*p-refcout = 2*/
Py_DECREF(p); /*p-refcout = 1*/
/*
END
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
*/
}
/* Release the thread state because we will never use
* the main interpreter, only sub interpreters created later. */
PyThreadState_Swap(NULL);
#ifdef WITH_THREAD
/* release the lock; now other threads can run */
PyEval_ReleaseLock();
#endif
}
return OK;
}
Another change I've made in the attached file is to Py_DECREF(p) in
get_interpreter, which will remove leaky reference to the PyCObject with the
interpreter data. This was not a real problem, but now I see fewer leaks in
BoundsChecker :-).
--
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] Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[
http://issues.apache.org/jira/browse/MODPYTHON-77?page=comments#action_12320931
]
Jim Gallacher commented on MODPYTHON-77:
Well, maybe I've just having one of those days, but when when I apply the patch
using:
patch -p0 diff3.txt
I get the following error:
Hunk #1 succeeded at 149 with fuzz 1.
Hunk #2 FAILED at 518.
Hunk #3 succeeded at 509 with fuzz 2 (offset -17 lines).
1 out of 5 hunks FAILED -- saving rejects to file mod_python.c.rej
and in mod_python.c.rej:
***
*** 517,526
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
- /* Release the thread state because we will never use
- * the main interpreter, only sub interpreters created later. */
- PyThreadState_Swap(NULL);
-
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
--- 518,523
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
It does not matter if the failed hunk is applied or not - apache fails to start
and so the unit tests fail. This is for mpm_prefork. I don't have time to test
it on mpm-worker just now. That will have to wait until Monday.
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3
--
Key: MODPYTHON-77
URL: http://issues.apache.org/jira/browse/MODPYTHON-77
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4
Environment: Python = 2.3
Reporter: Boyan Boyadjiev
Attachments: diff.txt, diff2.txt, diff3.txt, mod_python.c
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3 because of the PEP 311 (Simplified Global
Interpreter Lock Acquisition for Extensions):
...
Limitations and Exclusions
This proposal identifies a solution for extension authors with
complex multi-threaded requirements, but that only require a
single PyInterpreterState. There is no attempt to cater for
extensions that require multiple interpreter states. At the time
of writing, no extension has been identified that requires
multiple PyInterpreterStates, and indeed it is not clear if that
facility works correctly in Python itself.
...
For mod_python this means, that complex Python extensions won't work any more
with Python = 2.3, because they are supposed to work only with the first
interpreter state initialized for the current process (a problem we
experienced). The first interpreter state is not used by mod_python after the
python_init is called.
One solution, which works fine for me, is to save the first interpreter state
into the interpreters dictionary in the function python_init
(MAIN_INTERPRETER is used as a key):
static int python_init(apr_pool_t *p, apr_pool_t *ptemp,
apr_pool_t *plog, server_rec *s)
{
...
/* initialize global Python interpreter if necessary */
if (! Py_IsInitialized())
{
/* initialze the interpreter */
Py_Initialize();
#ifdef WITH_THREAD
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, s,
python_init: PyDict_New() failed! No more memory?);
exit(1);
}
{
/*
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
BEGIN
*/
PyObject *p = 0;
interpreterdata * idata = (interpreterdata
*)malloc(sizeof(interpreterdata));
PyThreadState* currentThreadState = PyThreadState_Get();
PyInterpreterState *istate = currentThreadState-interp;
idata-istate = istate;
/* obcallback will be created on first use */
idata-obcallback = NULL;
p = PyCObject_FromVoidPtr((void ) idata, NULL); /*p-refcout = 1*/
PyDict_SetItemString(interpreters, MAIN_INTERPRETER, p);
/*p-refcout = 2*/
Py_DECREF(p); /*p-refcout = 1*/
/*
END
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
*/
}
/* Release the thread state because we will never use
* the main interpreter, only sub interpreters created later. */
PyThreadState_Swap(NULL);
#ifdef WITH_THREAD
/* release the lock; now other
[jira] Commented: (MODPYTHON-80) Compile problem on IRIX
[ http://issues.apache.org/jira/browse/MODPYTHON-80?page=comments#action_12329541 ] Jim Gallacher commented on MODPYTHON-80: The fix is trivial. I'll commit the changes. Index: dist/Makefile.in === --- dist/Makefile.in(revision 280687) +++ dist/Makefile.in(working copy) @@ -44,10 +44,10 @@ exit 1 mod_python: - ln -s ../lib/python/mod_python + ln -s ../lib/python/mod_python mod_python src: - ln -s ../src + ln -s ../src src clean: rm -rf mod_python build dist Compile problem on IRIX --- Key: MODPYTHON-80 URL: http://issues.apache.org/jira/browse/MODPYTHON-80 Project: mod_python Type: Bug Components: core Versions: 3.2.0, 3.1.3, 3.1.4 Environment: Sgi IRIX 6.5.28 Reporter: Jim Gallacher Priority: Minor Sgi IRIX 6.5.28 Originally reported by Zach McDanel: Python 2.4.1, removed a reference in makefile to libmpc cause it was causing problems with mod_python compile and Apache 2.0.54 mod_python 3.1.4 this is the error I'm getting, I tracked down that it occurs in dist/Makefile ln -s ../lib/python/mod_python Insufficient arguments Usage: ln [-fis] file1 file2 ln [-fis] file1 ... file2 dir *** Error code 2 (bu21) *** Error code 1 (bu21) Further correspondence with Zach confirms that the behaviour of ln on IRIX is different than Linux or FreeBSD. -- 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] Assigned: (MODPYTHON-80) Compile problem on IRIX
[ http://issues.apache.org/jira/browse/MODPYTHON-80?page=all ] Jim Gallacher reassigned MODPYTHON-80: -- Assign To: Jim Gallacher Compile problem on IRIX --- Key: MODPYTHON-80 URL: http://issues.apache.org/jira/browse/MODPYTHON-80 Project: mod_python Type: Bug Components: core Versions: 3.2.0, 3.1.3, 3.1.4 Environment: Sgi IRIX 6.5.28 Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor Sgi IRIX 6.5.28 Originally reported by Zach McDanel: Python 2.4.1, removed a reference in makefile to libmpc cause it was causing problems with mod_python compile and Apache 2.0.54 mod_python 3.1.4 this is the error I'm getting, I tracked down that it occurs in dist/Makefile ln -s ../lib/python/mod_python Insufficient arguments Usage: ln [-fis] file1 file2 ln [-fis] file1 ... file2 dir *** Error code 2 (bu21) *** Error code 1 (bu21) Further correspondence with Zach confirms that the behaviour of ln on IRIX is different than Linux or FreeBSD. -- 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-70) Add configure --with-max-locks option to set MAX_LOCKS.
[ http://issues.apache.org/jira/browse/MODPYTHON-70?page=all ] Jim Gallacher closed MODPYTHON-70: -- Assign To: Jim Gallacher Fixed Add configure --with-max-locks option to set MAX_LOCKS. --- Key: MODPYTHON-70 URL: http://issues.apache.org/jira/browse/MODPYTHON-70 Project: mod_python Type: New Feature Components: core Versions: 3.2.0 Environment: All Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Trivial Fix For: 3.2.0 MAX_LOCKS in src/include/mod_python.h is currently hard coded (currently 32). Since the number of mutexes on some systems is limited, users may prefer to use a different number when compiling mod_python. The now configure would be --with-max-locks=INTERGER. eg. $ ./configure --with-max-locks=4 The default should also be lower than 32. Grisha has suggested 8. I'll commit the changes shortly. -- 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] Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[
http://issues.apache.org/jira/browse/MODPYTHON-77?page=comments#action_12356614
]
Jim Gallacher commented on MODPYTHON-77:
Tested gilstate.tar.gz on mpm-prefork. Error log output:
[Wed Nov 02 10:40:20 2005] [notice] Apache/2.0.54 (Debian GNU/Linux) DAV/2
SVN/1.2.0 mod_python/3.2.4b Python/2.3.5 PHP/4.4.0-1 configured -- resuming
normal operations
[Wed Nov 02 10:40:57 2005] [notice] mod_python: (Re)importing module 'mptest'
[Wed Nov 02 10:40:57 2005] [error] BEGIN: CALLBACK
[Wed Nov 02 10:40:57 2005] [error] EXCEPTION: file() constructor not accessible
in restricted mode
[Wed Nov 02 10:40:57 2005] [error] FINISH: CALLBACK
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3
--
Key: MODPYTHON-77
URL: http://issues.apache.org/jira/browse/MODPYTHON-77
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4
Environment: Python = 2.3
Reporter: Boyan Boyadjiev
Attachments: diff.txt, diff2.txt, diff3.txt, gil_test.c, gilstate.tar.gz,
mod_python.c, mod_python.c.diff, mod_python.h.diff, src.zip
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3 because of the PEP 311 (Simplified Global
Interpreter Lock Acquisition for Extensions):
...
Limitations and Exclusions
This proposal identifies a solution for extension authors with
complex multi-threaded requirements, but that only require a
single PyInterpreterState. There is no attempt to cater for
extensions that require multiple interpreter states. At the time
of writing, no extension has been identified that requires
multiple PyInterpreterStates, and indeed it is not clear if that
facility works correctly in Python itself.
...
For mod_python this means, that complex Python extensions won't work any more
with Python = 2.3, because they are supposed to work only with the first
interpreter state initialized for the current process (a problem we
experienced). The first interpreter state is not used by mod_python after the
python_init is called.
One solution, which works fine for me, is to save the first interpreter state
into the interpreters dictionary in the function python_init
(MAIN_INTERPRETER is used as a key):
static int python_init(apr_pool_t *p, apr_pool_t *ptemp,
apr_pool_t *plog, server_rec *s)
{
...
/* initialize global Python interpreter if necessary */
if (! Py_IsInitialized())
{
/* initialze the interpreter */
Py_Initialize();
#ifdef WITH_THREAD
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, s,
python_init: PyDict_New() failed! No more memory?);
exit(1);
}
{
/*
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
BEGIN
*/
PyObject *p = 0;
interpreterdata * idata = (interpreterdata
*)malloc(sizeof(interpreterdata));
PyThreadState* currentThreadState = PyThreadState_Get();
PyInterpreterState *istate = currentThreadState-interp;
idata-istate = istate;
/* obcallback will be created on first use */
idata-obcallback = NULL;
p = PyCObject_FromVoidPtr((void ) idata, NULL); /*p-refcout = 1*/
PyDict_SetItemString(interpreters, MAIN_INTERPRETER, p);
/*p-refcout = 2*/
Py_DECREF(p); /*p-refcout = 1*/
/*
END
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
*/
}
/* Release the thread state because we will never use
* the main interpreter, only sub interpreters created later. */
PyThreadState_Swap(NULL);
#ifdef WITH_THREAD
/* release the lock; now other threads can run */
PyEval_ReleaseLock();
#endif
}
return OK;
}
Another change I've made in the attached file is to Py_DECREF(p) in
get_interpreter, which will remove leaky reference to the PyCObject with the
interpreter data. This was not a real problem, but now I see fewer leaks in
BoundsChecker :-).
--
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] Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[
http://issues.apache.org/jira/browse/MODPYTHON-77?page=comments#action_12356864
]
Jim Gallacher commented on MODPYTHON-77:
Patched 3.2.4b with diff from grahamd_20051105.tar.gz. Unit tests and gilstate
test pass on Debian stable (sarge) and mpm-prefork.
[Sat Nov 05 17:21:36 2005] [notice] mod_python: Creating 8 session mutexes
based on 20 max processes and 0 max threads.
[Sat Nov 05 17:21:37 2005] [notice] Apache/2.0.54 (Debian GNU/Linux)
mod_python/3.2.4b Python/2.3.5 configured -- resuming normal operations
[Sat Nov 05 17:37:13 2005] [notice] mod_python: (Re)importing module 'mptest'
[Sat Nov 05 17:37:13 2005] [error] BEGIN: CALLBACK
[Sat Nov 05 17:37:13 2005] [error] FINISH: CALLBACK
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3
--
Key: MODPYTHON-77
URL: http://issues.apache.org/jira/browse/MODPYTHON-77
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4
Environment: Python = 2.3
Reporter: Boyan Boyadjiev
Attachments: diff.txt, diff2.txt, diff3.txt, gil_test.c, gilstate.tar.gz,
grahamd_20051105.tar.gz, mod_python.c, mod_python.c.diff, mod_python.h.diff,
src.zip
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3 because of the PEP 311 (Simplified Global
Interpreter Lock Acquisition for Extensions):
...
Limitations and Exclusions
This proposal identifies a solution for extension authors with
complex multi-threaded requirements, but that only require a
single PyInterpreterState. There is no attempt to cater for
extensions that require multiple interpreter states. At the time
of writing, no extension has been identified that requires
multiple PyInterpreterStates, and indeed it is not clear if that
facility works correctly in Python itself.
...
For mod_python this means, that complex Python extensions won't work any more
with Python = 2.3, because they are supposed to work only with the first
interpreter state initialized for the current process (a problem we
experienced). The first interpreter state is not used by mod_python after the
python_init is called.
One solution, which works fine for me, is to save the first interpreter state
into the interpreters dictionary in the function python_init
(MAIN_INTERPRETER is used as a key):
static int python_init(apr_pool_t *p, apr_pool_t *ptemp,
apr_pool_t *plog, server_rec *s)
{
...
/* initialize global Python interpreter if necessary */
if (! Py_IsInitialized())
{
/* initialze the interpreter */
Py_Initialize();
#ifdef WITH_THREAD
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, s,
python_init: PyDict_New() failed! No more memory?);
exit(1);
}
{
/*
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
BEGIN
*/
PyObject *p = 0;
interpreterdata * idata = (interpreterdata
*)malloc(sizeof(interpreterdata));
PyThreadState* currentThreadState = PyThreadState_Get();
PyInterpreterState *istate = currentThreadState-interp;
idata-istate = istate;
/* obcallback will be created on first use */
idata-obcallback = NULL;
p = PyCObject_FromVoidPtr((void ) idata, NULL); /*p-refcout = 1*/
PyDict_SetItemString(interpreters, MAIN_INTERPRETER, p);
/*p-refcout = 2*/
Py_DECREF(p); /*p-refcout = 1*/
/*
END
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
*/
}
/* Release the thread state because we will never use
* the main interpreter, only sub interpreters created later. */
PyThreadState_Swap(NULL);
#ifdef WITH_THREAD
/* release the lock; now other threads can run */
PyEval_ReleaseLock();
#endif
}
return OK;
}
Another change I've made in the attached file is to Py_DECREF(p) in
get_interpreter, which will remove leaky reference to the PyCObject with the
interpreter data. This was not a real problem, but now I see fewer leaks in
BoundsChecker :-).
--
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:
[jira] Resolved: (MODPYTHON-87) psp_parser: replaces \n on \n
[ http://issues.apache.org/jira/browse/MODPYTHON-87?page=all ] Jim Gallacher resolved MODPYTHON-87: Resolution: Fixed Assign To: Jim Gallacher psp_parser: replaces \n on \n --- Key: MODPYTHON-87 URL: http://issues.apache.org/jira/browse/MODPYTHON-87 Project: mod_python Type: Bug Versions: 3.2 Environment: Debian unstable, mod_python/3.2.0b Python/2.3.5 Reporter: Anton Kuzmin Assignee: Jim Gallacher Fix For: 3.2 $ cat mptest.psp html body You see (#92;n) in the test result. If you see () then the test fails.br / BEGIN TESTbr / (\n) br /END TEST /body /html The result on the screen is: You see (\n) in the test result. If you see () then the test fails. BEGIN TEST ( ) END TEST $ cat .htaccess AddHandler mod_python .psp PythonHandler mod_python.psp PythonDebug On -- 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] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
[
http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12358568
]
Jim Gallacher commented on MODPYTHON-93:
The FieldStorage methods get, getitems, has_key, __len__, getfirst and getlist
*all* iterate over the complete list of fields each time they are called and so
would all benefit from some kind of indexing scheme. Here is a bit of code that
will give you some idea of what I have in mind.
class FieldStorage:
def __init__():
self.index = {} # holds references to the Field objects and can be
used as an index.
self.list = []
... blah blah blah ...
... create the field and get it's name ...
self.list.append(field)
if name in self.index:
self.index[name].append(field)
else:
self.index[name] = [field,]
def __getitem__(self, key):
if key not in self.index:
raise KeyError, key
found = self.index[key]
if len(found) == 1:
return found[0]
else:
return found
The other FieldStorage methods would need to be refactored to take advantage of
the index.
Improve util.FieldStorage efficiency
Key: MODPYTHON-93
URL: http://issues.apache.org/jira/browse/MODPYTHON-93
Project: mod_python
Type: Improvement
Components: core
Versions: 3.3
Reporter: Jim Gallacher
Assignee: Jim Gallacher
Priority: Minor
Form fields are saved as a list in a FieldStorage class instance. The class
implements a __getitem__ method to provide dict-like behaviour. This method
iterates over the complete list for every call to __getitem__. Applications
that need to access all the fields when processing the form will show O(n^2)
behaviour where n == the number of form fields. This overhead could be
avoided by creating a dict (to use as an index) when the FieldStorage
instance is created.
Mike Looijmans has been investigating StringField and Field as well. It is
probably reasonable to include information on his work in this issue as well,
so that we can consider all of these efficiency issues in toto.
--
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-99) accessing some request or server object members causes a segfault
[ http://issues.apache.org/jira/browse/MODPYTHON-99?page=all ] Jim Gallacher updated MODPYTHON-99: --- Attachment: md-20051209.diff Martin's patch (md-20051209.diff) accessing some request or server object members causes a segfault - Key: MODPYTHON-99 URL: http://issues.apache.org/jira/browse/MODPYTHON-99 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Jim Gallacher Priority: Critical Attachments: md-20051209.diff Martin Devara discovered a segfault when accessing some request object members. For example: def handler(req): req.content_type = text/plain req.write(EE\n) a = getattr(req,allowed_methods); return apache.OK Futher investigation revealed problems with several getter functions in requestobject.c and serverobject.c. The root of the problem seems to be pointer dereferencing errors in the getter code. The affected functions and the members which use them are: src/requestobject.c getreq_rec_ml allowed_methods getreq_rec_ah content_languages allowed_xmethods src/serverobject.c getsrv_recmbr_ah names wild_names Martin has provided a patch to fix the bug. (Thanks to Martin for tracking this down and providing the fix.) -- 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] Commented: (MODPYTHON-99) accessing some request or server object members causes a segfault
[ http://issues.apache.org/jira/browse/MODPYTHON-99?page=comments#action_12359969 ] Jim Gallacher commented on MODPYTHON-99: Should we be unit testing the getters and setters for all request and server object members? accessing some request or server object members causes a segfault - Key: MODPYTHON-99 URL: http://issues.apache.org/jira/browse/MODPYTHON-99 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Jim Gallacher Priority: Critical Attachments: md-20051209.diff Martin Devara discovered a segfault when accessing some request object members. For example: def handler(req): req.content_type = text/plain req.write(EE\n) a = getattr(req,allowed_methods); return apache.OK Futher investigation revealed problems with several getter functions in requestobject.c and serverobject.c. The root of the problem seems to be pointer dereferencing errors in the getter code. The affected functions and the members which use them are: src/requestobject.c getreq_rec_ml allowed_methods getreq_rec_ah content_languages allowed_xmethods src/serverobject.c getsrv_recmbr_ah names wild_names Martin has provided a patch to fix the bug. (Thanks to Martin for tracking this down and providing the fix.) -- 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] Commented: (MODPYTHON-99) accessing some request or server object members causes a segfault
[ http://issues.apache.org/jira/browse/MODPYTHON-99?page=comments#action_12360048 ] Jim Gallacher commented on MODPYTHON-99: The req.allowed_xmethods, req.allowed_methods documentation states that these are a tuples. It seems req.content_languages, server.names, server.wild_names are undocumented. I don't have mod_python 3.1.4 handy to test but certainly the relavent code has not changed since then. If the problem existed there then I don't think we need to worry about changing the return type since nobody would have been able to access these members anyway. accessing some request or server object members causes a segfault - Key: MODPYTHON-99 URL: http://issues.apache.org/jira/browse/MODPYTHON-99 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Jim Gallacher Priority: Critical Attachments: md-20051209.diff Martin Devara discovered a segfault when accessing some request object members. For example: def handler(req): req.content_type = text/plain req.write(EE\n) a = getattr(req,allowed_methods); return apache.OK Futher investigation revealed problems with several getter functions in requestobject.c and serverobject.c. The root of the problem seems to be pointer dereferencing errors in the getter code. The affected functions and the members which use them are: src/requestobject.c getreq_rec_ml allowed_methods getreq_rec_ah content_languages allowed_xmethods src/serverobject.c getsrv_recmbr_ah names wild_names Martin has provided a patch to fix the bug. (Thanks to Martin for tracking this down and providing the fix.) -- 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-99) accessing some request or server object members causes a segfault
[ http://issues.apache.org/jira/browse/MODPYTHON-99?page=all ] Jim Gallacher resolved MODPYTHON-99: Fix Version: 3.2 Resolution: Fixed Assign To: Jim Gallacher accessing some request or server object members causes a segfault - Key: MODPYTHON-99 URL: http://issues.apache.org/jira/browse/MODPYTHON-99 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Critical Fix For: 3.2 Attachments: md-20051209.diff Martin Devara discovered a segfault when accessing some request object members. For example: def handler(req): req.content_type = text/plain req.write(EE\n) a = getattr(req,allowed_methods); return apache.OK Futher investigation revealed problems with several getter functions in requestobject.c and serverobject.c. The root of the problem seems to be pointer dereferencing errors in the getter code. The affected functions and the members which use them are: src/requestobject.c getreq_rec_ml allowed_methods getreq_rec_ah content_languages allowed_xmethods src/serverobject.c getsrv_recmbr_ah names wild_names Martin has provided a patch to fix the bug. (Thanks to Martin for tracking this down and providing the fix.) -- 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] Reopened: (MODPYTHON-107) mod_python.publisher shouldn't flush result when written.
[ http://issues.apache.org/jira/browse/MODPYTHON-107?page=all ] Jim Gallacher reopened MODPYTHON-107: - Ooops. Resolved the wrong issue. mod_python.publisher shouldn't flush result when written. - Key: MODPYTHON-107 URL: http://issues.apache.org/jira/browse/MODPYTHON-107 Project: mod_python Type: Improvement Components: publisher Versions: 3.2 Reporter: Graham Dumpleton Fix For: 3.2 In mod_python.publisher, the result returned from a published function is returned as the content of the response after it has been converted to a string, using: req.write(result) In doing this, the second argument of req.write() is defaulting to '1', which indicates that the output should be flushed immediately. This fact prevents an output filter like CONTENT_LENGTH being used in conjunction with mod_python.publisher. This output filter will add a content length header to the response, but only if it is able to read the full content the first time the output filter is called. Because the output is flushed at this point, the output filter isn't able to do that, as it gets called twice. The first time it gets called will be with the actual content, the second time happens when the handler returns apache.OK and is effectively a null output call to force the output filter to be closed off. If instead the output is written as: req.write(result,0) the output will not be flushed immediately and instead will be output in one call when apache.OK is returned. There is no loss of efficiency in doing this and instead it will actually eliminate a redundant call into the output filter. For further details of this issue see discussion in: http://www.mail-archive.com/python-dev@httpd.apache.org/msg00951.html This makes one wander if there should be a configurable option for mod_python.psp to tell it not to flush output as well so that CONTENT_LENGTH could be used in that case as well. ??? -- 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-105) mod_python.publisher should not discard content for HEAD request.
[ http://issues.apache.org/jira/browse/MODPYTHON-105?page=all ] Jim Gallacher resolved MODPYTHON-105: - Fix Version: 3.2 Resolution: Fixed mod_python.publisher should not discard content for HEAD request. - Key: MODPYTHON-105 URL: http://issues.apache.org/jira/browse/MODPYTHON-105 Project: mod_python Type: Bug Components: publisher Versions: 3.2 Reporter: Graham Dumpleton Fix For: 3.2 In addressing MODPYTHON-71, mod_python.publisher code was changed to read: if req.method!='HEAD': req.write(result) This change should not really have been made and it should be changed back to what was there before, ie., just: req.write(result) This is because even when HEAD is used, any output is sent through any output filters before Apache finally decides to throw it away. That mod_python.publisher is not allowing the data through, may cause issues for any output filters that are doing something with the output and expect it all to be there. As an an example of an Apache module that uses output filters to do stuff, there is mod_cache. Luckily in that case, a HEAD request is one of various cases where mod_cache decides it will not use the output. This does not mean though that some other output filter that someone is using might expect content to be there for HEAD. In summary, one could also say that if a user wants to not output anything for a HEAD request, that is there decision, but mod_python.publisher should not be making that decision for them. Because HEAD didn't work before 3.2 anyway, it is possibly not essential that this issue be fixed before 3.2 release, but if other changes need to be made, it probably should. -- 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] Commented: (MODPYTHON-110) Tru64 v5.1B : mod_python prevents httpd child restart after previous slave has crashed
[ http://issues.apache.org/jira/browse/MODPYTHON-110?page=comments#action_12363123 ] Jim Gallacher commented on MODPYTHON-110: - Discussion started on 2005-11-21: http://article.gmane.org/gmane.comp.apache.mod-python.devel/1875 Tru64 v5.1B : mod_python prevents httpd child restart after previous slave has crashed -- Key: MODPYTHON-110 URL: http://issues.apache.org/jira/browse/MODPYTHON-110 Project: mod_python Type: Bug Components: core Versions: 3.2 Environment: HP Tru64 5.1B / Apache 2.0.55 with mpm-worker Reporter: Michel Jouvin (issue already discussed on the mailing list...) I recently installed mod_python 3.2b5 on Apache 2.0.54/2.0.55. I am running with problems if httpd slave process segfaults or is killed. In this case, new httpd child doesn't initialize properly and master process restart the max number of processes/threads. We are running Apache with the MPM worker (on Tru64 platform). This behaviour appears only if mod_python is loaded into Apache. this doesn't seem to be related to mod_python usage : this can happen if you load mod_python even if no URL is configured to use it. You can easily reproduce the problem on Tru64 platform (tested on several systems with different configuration and different level of patches) by doing 'kill -KILL' of an Apache slave process. This happens even on a server without any mod_python activity (no URL configured to run a Python script) and with only the Apache standard modules loaded (no PHP, no SVN...). This is a real pain because on our production server we regularly have httpd child crashed because of PHP. In this situation, httpd master doesn't succeed to restart properly a new child. -- 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-122) configure fails when using bash 3.1.x
[ http://issues.apache.org/jira/browse/MODPYTHON-122?page=all ] Jim Gallacher updated MODPYTHON-122: Description: A bug in bash 3.1 causes configure to fail. This has been reported on recent versions of Gentoo and and discussed on the mod_python mailing list: http://bugs.gentoo.org/show_bug.cgi?id=118948 http://www.modpython.org/pipermail/mod_python/2006-January/019965.html http://www.modpython.org/pipermail/mod_python/2006-January/019969.html According to the gentoo bug report, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\//g` fixes it for bash 3.1. I wonder why mod_python is using \\ since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest mod_python adopts the gentoo fix, or avoids the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d ''` was: A bug in bash 3.1 causes configure to fail. This has been report on recent versions of Gentoo and and deicussed on the mod_python mailing list: http://bugs.gentoo.org/show_bug.cgi?id=118948 http://www.modpython.org/pipermail/mod_python/2006-January/019965.html http://www.modpython.org/pipermail/mod_python/2006-January/019969.html According to the gentoo bug report, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\//g` fixes it for bash 3.1. I wonder why we are using \\ since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) on my system just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest we either adopt the gentoo fix, or avoid the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d ''` configure fails when using bash 3.1.x - Key: MODPYTHON-122 URL: http://issues.apache.org/jira/browse/MODPYTHON-122 Project: mod_python Type: Bug Components: core Versions: 3.1.4, 3.2 Environment: Any platform using bash 3.1.x Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor A bug in bash 3.1 causes configure to fail. This has been reported on recent versions of Gentoo and and discussed on the mod_python mailing list: http://bugs.gentoo.org/show_bug.cgi?id=118948 http://www.modpython.org/pipermail/mod_python/2006-January/019965.html http://www.modpython.org/pipermail/mod_python/2006-January/019969.html According to the gentoo bug report, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\//g` fixes it for bash 3.1. I wonder why mod_python is using \\ since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest mod_python adopts the gentoo fix, or avoids the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d ''` -- 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] Commented: (MODPYTHON-78) No support for Apache 2.2 yet
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=comments#action_12365923 ] Jim Gallacher commented on MODPYTHON-78: The following comment from Justin Erenkrantz was sent to the python-dev mailing list : FWIW, don't ever expect code that relies upon Win32's ERROR_SUCCESS to have actually worked anywhere else. The removal of that STATUS_IS_SUCCESS #define was to codify that APR_SUCCESS was really just 0. I think we did some digging in when we made this change and no Windows code ever returned ERROR_SUCCESS for the cases we cared about. -- justin No support for Apache 2.2 yet - Key: MODPYTHON-78 URL: http://issues.apache.org/jira/browse/MODPYTHON-78 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Nicolas Lehuen Fix For: 3.3 Attachments: jg-20060204-1.diff.zip See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some remarks by Jorey Bump, raised during the 3.2.1-BETA tests. -- 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] Assigned: (MODPYTHON-135) [SECURITY] A Security Issue with FileSession in 3.2.7
[ http://issues.apache.org/jira/browse/MODPYTHON-135?page=all ] Jim Gallacher reassigned MODPYTHON-135: --- Assign To: Jim Gallacher [SECURITY] A Security Issue with FileSession in 3.2.7 - Key: MODPYTHON-135 URL: http://issues.apache.org/jira/browse/MODPYTHON-135 Project: mod_python Type: Bug Components: session Versions: 3.2 Reporter: Graham Dumpleton Assignee: Jim Gallacher As announced on the mailing list: http://www.modpython.org/pipermail/mod_python/2006-February/020284.html If you are using the recently released mod_python 3.2.7 please beware that a security issue was discovered in the FileSession code. You are vulnerable only if you are using mod_python 3.2.7 AND you are using FileSession to keep sessions. FileSession is new in 3.2.7 and is not enabled by default, therefore if you are using mod_python Session in its default configuration you are not vulnerable. The extent of this vulnerability is limited. Only a user who already has an account (or some ability to write to the filesystem) on the system running httpd could exploit it, and to the best of our knowledge such a user could potentially cause httpd to execute arbitrary code. We are working on a security release of the next version of mod_python and expect it to be out shortly. Until then, please do not use FileSession. -- 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] Assigned: (MODPYTHON-119) DBM Session test shouldn't use default database.
[ http://issues.apache.org/jira/browse/MODPYTHON-119?page=all ]
Jim Gallacher reassigned MODPYTHON-119:
---
Assign To: Jim Gallacher
DBM Session test shouldn't use default database.
Key: MODPYTHON-119
URL: http://issues.apache.org/jira/browse/MODPYTHON-119
Project: mod_python
Type: Bug
Components: core
Versions: 3.2
Reporter: Graham Dumpleton
Assignee: Jim Gallacher
The test_Session_Session_conf() of test/test.py doesn't override the default
DBM session database name that would be used for prefork/worker MPM variants.
This means that if there is already an instance of Apache running as its
designated user which has already created the session database and the tests
are run as a different user, the test will fail. Further, if mod_python has
never previously been used and no session database exists, the test will
succeed, but when someone goes to use sessions in the installed mod_python,
it will fail in the case where the session database created by the test was
as a different user to that which Apache runs as.
The test suite should ensure that it overrides any defaults and stores such
databases in test suite document tree. It should possibly also ensure that
such transient files are removed so as not to create a problem on subsequent
tests.
Test might therefore be changed to:
def test_Session_Session_conf(self):
database = os.path.join(TESTHOME,mp_sess_test.dbm)
c = VirtualHost(*,
ServerName(test_Session_Session),
DocumentRoot(DOCUMENT_ROOT),
Directory(DOCUMENT_ROOT,
PythonOption('session_dbm %s' % database),
SetHandler(mod_python),
PythonHandler(tests::Session_Session),
PythonDebug(On)))
return str(c)
--
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] Assigned: (MODPYTHON-78) No support for Apache 2.2 yet
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=all ] Jim Gallacher reassigned MODPYTHON-78: -- Assign To: Jim Gallacher No support for Apache 2.2 yet - Key: MODPYTHON-78 URL: http://issues.apache.org/jira/browse/MODPYTHON-78 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Nicolas Lehuen Assignee: Jim Gallacher Fix For: 3.3 Attachments: jg-20060204-1.diff.zip See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some remarks by Jorey Bump, raised during the 3.2.1-BETA tests. -- 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] Commented: (MODPYTHON-138) Python.h should be included first
[ http://issues.apache.org/jira/browse/MODPYTHON-138?page=comments#action_12367796 ] Jim Gallacher commented on MODPYTHON-138: - Michel's patch does not work for Debian Linux. mod_python immediately segfaults. There was a different gcc warning, which I had not seen before: /usr/bin/libtool --silent --mode=compile gcc -prefer-pic -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -g -O2 -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -g -O2 -pthread -I/usr/include/apache2 -I/usr/include/apr-0 -I/usr/include/apr-0 -I/usr/include -I/tmp/mod_python/src/include -I/usr/include/apache2 -I/usr/include/python2.3 -c -o _apachemodule.lo _apachemodule.c touch _apachemodule.slo In file included from /usr/include/python2.3/Python.h:8, from /tmp/mod_python/src/include/mod_python.h:46, from _apachemodule.c:25: /usr/include/python2.3/pyconfig.h:865:1: warning: _XOPEN_SOURCE redefined command line:1:1: warning: this is the location of the previous definition Python.h should be included first - Key: MODPYTHON-138 URL: http://issues.apache.org/jira/browse/MODPYTHON-138 Project: mod_python Type: Bug Components: core Versions: 3.2 Environment: Tru64 5.1B, Python 2.4.1, Apache 2..55 Reporter: Michel Jouvin Assignee: Jim Gallacher Attachments: mod_python-3.2.6-tru64.patch I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. This change should have no impact on platforms where the current include order works. Affected files are : src/include/psp_parser.h src/include/mod_python.h src/include/psp_flex.h src/include/mod_python.h.in src/_pspmodule.c src/psp_parser.c I have a patch file available, I'll try to attach it to this issue if I manage to find how to do it... Michel -- 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] Commented: (MODPYTHON-138) Python.h should be included first
[ http://issues.apache.org/jira/browse/MODPYTHON-138?page=comments#action_12367797 ] Jim Gallacher commented on MODPYTHON-138: - I should have added that a similar error occurs 9 more times. Python.h should be included first - Key: MODPYTHON-138 URL: http://issues.apache.org/jira/browse/MODPYTHON-138 Project: mod_python Type: Bug Components: core Versions: 3.2 Environment: Tru64 5.1B, Python 2.4.1, Apache 2..55 Reporter: Michel Jouvin Assignee: Jim Gallacher Attachments: mod_python-3.2.6-tru64.patch I have a problem to build mod_pyton on Tru64 with the Python config I have. This is basically due to the fact that Python.h should be included first as its defines some macros used by standard includes. When included at the end of the includes, this results to some conflicts because the same include is included twice with a different macro value. This change should have no impact on platforms where the current include order works. Affected files are : src/include/psp_parser.h src/include/mod_python.h src/include/psp_flex.h src/include/mod_python.h.in src/_pspmodule.c src/psp_parser.c I have a patch file available, I'll try to attach it to this issue if I manage to find how to do it... Michel -- 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] Commented: (MODPYTHON-19) Add a section about security in the documentation
[ http://issues.apache.org/jira/browse/MODPYTHON-19?page=comments#action_12368618 ] Jim Gallacher commented on MODPYTHON-19: Another security discussion on the mod_python mailing list: http://www.modpython.org/pipermail/mod_python/2006-March/020482.html James Paige created a summary of this discussion: http://www.modpython.org/FAQ/faqw.py?req=all#3.28 Add a section about security in the documentation - Key: MODPYTHON-19 URL: http://issues.apache.org/jira/browse/MODPYTHON-19 Project: mod_python Type: Task Components: documentation Versions: 3.1.3 Reporter: Nicolas Lehuen A good beginning is this thread : http://www.modpython.org/pipermail/mod_python/2005-February/017297.html -- 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-53) Show link for subversion and JIRA on www.mod_python website
[ http://issues.apache.org/jira/browse/MODPYTHON-53?page=all ] Jim Gallacher updated MODPYTHON-53: --- Fix Version: 3.3 (was: 3.2.7) Show link for subversion and JIRA on www.mod_python website --- Key: MODPYTHON-53 URL: http://issues.apache.org/jira/browse/MODPYTHON-53 Project: mod_python Type: Wish Components: documentation Reporter: Jim Gallacher Priority: Trivial Fix For: 3.3 The mod_python website still has links to CVS repository, instead of subversion. Also, it would be nice if there was a link to JIRA. And if you are making changes to the website, might as well add a link to the python-dev list archive at gmane. http://dir.gmane.org/gmane.comp.apache.mod-python.devel -- 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] Assigned: (MODPYTHON-19) Add a section about security in the documentation
[ http://issues.apache.org/jira/browse/MODPYTHON-19?page=all ] Jim Gallacher reassigned MODPYTHON-19: -- Assign To: Jim Gallacher Add a section about security in the documentation - Key: MODPYTHON-19 URL: http://issues.apache.org/jira/browse/MODPYTHON-19 Project: mod_python Type: Task Components: documentation Versions: 3.1.3 Reporter: Nicolas Lehuen Assignee: Jim Gallacher A good beginning is this thread : http://www.modpython.org/pipermail/mod_python/2005-February/017297.html -- 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-119) DBM Session test shouldn't use default database.
[ http://issues.apache.org/jira/browse/MODPYTHON-119?page=all ]
Jim Gallacher resolved MODPYTHON-119:
-
Fix Version: 3.3
Resolution: Fixed
DBM Session test shouldn't use default database.
Key: MODPYTHON-119
URL: http://issues.apache.org/jira/browse/MODPYTHON-119
Project: mod_python
Type: Bug
Components: core
Versions: 3.2.7
Reporter: Graham Dumpleton
Assignee: Jim Gallacher
Fix For: 3.3
The test_Session_Session_conf() of test/test.py doesn't override the default
DBM session database name that would be used for prefork/worker MPM variants.
This means that if there is already an instance of Apache running as its
designated user which has already created the session database and the tests
are run as a different user, the test will fail. Further, if mod_python has
never previously been used and no session database exists, the test will
succeed, but when someone goes to use sessions in the installed mod_python,
it will fail in the case where the session database created by the test was
as a different user to that which Apache runs as.
The test suite should ensure that it overrides any defaults and stores such
databases in test suite document tree. It should possibly also ensure that
such transient files are removed so as not to create a problem on subsequent
tests.
Test might therefore be changed to:
def test_Session_Session_conf(self):
database = os.path.join(TESTHOME,mp_sess_test.dbm)
c = VirtualHost(*,
ServerName(test_Session_Session),
DocumentRoot(DOCUMENT_ROOT),
Directory(DOCUMENT_ROOT,
PythonOption('session_dbm %s' % database),
SetHandler(mod_python),
PythonHandler(tests::Session_Session),
PythonDebug(On)))
return str(c)
--
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] Assigned: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=all ] Jim Gallacher reassigned MODPYTHON-111: --- Assign To: Jim Gallacher Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: documentation, session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca Assignee: Jim Gallacher When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- 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] Assigned: (MODPYTHON-131) Make name of mutex directory configurable.
[ http://issues.apache.org/jira/browse/MODPYTHON-131?page=all ] Jim Gallacher reassigned MODPYTHON-131: --- Assign To: Jim Gallacher Make name of mutex directory configurable. -- Key: MODPYTHON-131 URL: http://issues.apache.org/jira/browse/MODPYTHON-131 Project: mod_python Type: Improvement Components: core Versions: 3.2.7 Reporter: Graham Dumpleton Assignee: Jim Gallacher Creating an issue for this so it can be tracked. Been pointed out in: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01271.html that on Mandriva Linux, that is is necessary to manually change the mutex directory in mod_python.c source code. Area of code is: #if !defined(OS2) !defined(WIN32) !defined(BEOS) !defined(NETWARE) char fname[255]; snprintf(fname, 255, /tmp/mpmtx%d%d, glb-parent_pid, n); #else char *fname = NULL; #endif There should be an option to configure program to allow this to be more easily changed. Way of changing the value through Apache configuration to also be investigated further. -- 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] Assigned: (MODPYTHON-108) Let Cookie support new HttpOnly property to prevent cross-site cookie stealing
[ http://issues.apache.org/jira/browse/MODPYTHON-108?page=all ] Jim Gallacher reassigned MODPYTHON-108: --- Assign To: Jim Gallacher Let Cookie support new HttpOnly property to prevent cross-site cookie stealing -- Key: MODPYTHON-108 URL: http://issues.apache.org/jira/browse/MODPYTHON-108 Project: mod_python Type: Improvement Components: core Versions: 3.2.7, 3.1.4, 3.3 Reporter: Deron Meranda Assignee: Jim Gallacher Priority: Minor The Cookie.Cookie class does not allow the new httponly cookie property to be set. It needs to be added to the valid slots on the cookie metaclass. Also note that like the secure cookie attribute, it is simple a boolean flag without any value. The HttpOnly flag was invented by Microsoft but seeing widespread support as a way to prevent cross-site scripting from stealing cookies using client-side Javascript. This is especially important for security-sensitive cookies, such as session keys. The mod_python session object should also explicitly set the HttpOnly property on the cookies it creates. See also these related references: 1. http://msdn.microsoft.com/workshop/author/dhtml/httponly_cookies.asp 2. http://search.cpan.org/~mschout/Apache-AuthCookie-3.08/lib/Apache2/AuthCookie.pm 3. https://bugzilla.mozilla.org/show_bug.cgi?id=178993 4. http://www.linux.com/howtos/Secure-Programs-HOWTO/cross-site-malicious-content.shtml -- 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-122) configure fails when using bash 3.1.x
[ http://issues.apache.org/jira/browse/MODPYTHON-122?page=all ] Jim Gallacher updated MODPYTHON-122: Fix Version: 3.2.x (was: 3.3) configure fails when using bash 3.1.x - Key: MODPYTHON-122 URL: http://issues.apache.org/jira/browse/MODPYTHON-122 Project: mod_python Type: Bug Components: core Versions: 3.1.4, 3.2.7 Environment: Any platform using bash 3.1.x Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor Fix For: 3.2.x A bug in bash 3.1 causes configure to fail. This has been reported on recent versions of Gentoo and and discussed on the mod_python mailing list: http://bugs.gentoo.org/show_bug.cgi?id=118948 http://www.modpython.org/pipermail/mod_python/2006-January/019965.html http://www.modpython.org/pipermail/mod_python/2006-January/019969.html According to the gentoo bug report, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\//g` fixes it for bash 3.1. I wonder why mod_python is using \\ since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest mod_python adopts the gentoo fix, or avoids the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d ''` -- 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-119) DBM Session test shouldn't use default database.
[ http://issues.apache.org/jira/browse/MODPYTHON-119?page=all ]
Jim Gallacher updated MODPYTHON-119:
Fix Version: 3.2.x
(was: 3.3)
DBM Session test shouldn't use default database.
Key: MODPYTHON-119
URL: http://issues.apache.org/jira/browse/MODPYTHON-119
Project: mod_python
Type: Bug
Components: core
Versions: 3.2.7
Reporter: Graham Dumpleton
Assignee: Jim Gallacher
Fix For: 3.2.x
The test_Session_Session_conf() of test/test.py doesn't override the default
DBM session database name that would be used for prefork/worker MPM variants.
This means that if there is already an instance of Apache running as its
designated user which has already created the session database and the tests
are run as a different user, the test will fail. Further, if mod_python has
never previously been used and no session database exists, the test will
succeed, but when someone goes to use sessions in the installed mod_python,
it will fail in the case where the session database created by the test was
as a different user to that which Apache runs as.
The test suite should ensure that it overrides any defaults and stores such
databases in test suite document tree. It should possibly also ensure that
such transient files are removed so as not to create a problem on subsequent
tests.
Test might therefore be changed to:
def test_Session_Session_conf(self):
database = os.path.join(TESTHOME,mp_sess_test.dbm)
c = VirtualHost(*,
ServerName(test_Session_Session),
DocumentRoot(DOCUMENT_ROOT),
Directory(DOCUMENT_ROOT,
PythonOption('session_dbm %s' % database),
SetHandler(mod_python),
PythonHandler(tests::Session_Session),
PythonDebug(On)))
return str(c)
--
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] Commented: (MODPYTHON-124) Improvements associated with the req.ap_auth_type attribute.
[ http://issues.apache.org/jira/browse/MODPYTHON-124?page=comments#action_12369763 ] Jim Gallacher commented on MODPYTHON-124: - I've been playing around with the changes implemented here and I like it. However I wonder why auth_name and auth_type are methods of request instead of members? Also, auth_type() and ap_auth_type both give access to AuthType, which I think is confusing. Why do we need both? I'm not in favour of the ap_auth_type name as I think this may be one of the few places where we prepend ap_ to a method or attribute. This exposes an underlying implementation detail which is not of interest to the user and makes it more difficult to find in the documentation index. I'll upload a patch of an alternative implemenation. Improvements associated with the req.ap_auth_type attribute. Key: MODPYTHON-124 URL: http://issues.apache.org/jira/browse/MODPYTHON-124 Project: mod_python Type: Improvement Components: core Versions: 3.3 Reporter: Graham Dumpleton Assignee: Graham Dumpleton Fix For: 3.3 The req.ap_auth_type attribute is set to the authentication type corresponding to the type of authentication processing successfully carried out in respect of a request. For example, if one has Apache configuration: AuthType Basic AuthName Restricted Files AuthUserFile /usr/local/apache/passwd/passwords Require valid-user it is expected that the request uses basic authentication header as appropriate. These headers will be dealt with by inbuilt Apache core module. Upon successful authentication, the Apache core module will set req.ap_auth_type attribute to be Basic and set req.user to the user ID of the logged in user. If instead Apache support for digest authentication was used, eg: AuthType Digest ... then req.ap_auth_type attribute will be set to Digest. If authentication was not requested, ie., no AuthType directive, the req.ap_auth_type is set to Python None. The intent is that you should be able to implement authentication handlers in mod_python using PythonAuthenHandler, but you can't actually do this correctly at the moment as there are a few things missing. Firstly, in order to trigger the PythonAuthenHandler, you must still define the AuthType/AuthName/Require directives. In order to ensure that our authentication handler is triggered and not the builtin ones or some other one, the AuthType directive should specify a string other than Basic or Digest. This would be a name we choose and can basically be anything. For example, you might choose a descriptive name like Python-Basic-DBM to denote basic authentication is used against a DBM database but using the Python authentication handler. AuthType Python-Basic-DBM AuthName Web Application Require valid-user PythonAuthenHandler basicdbmauth PythonOption basicdbmauth.UserDatabase /.../users.dbm When the authentication handler in basicdbmauth is called, the req.ap_auth_type field is still None. This is because authentication hasn't succeed yet. In terms of being able to implement the authentication handler correctly, the first problem is that there is no way to access the actual value associated with the AuthType directive. This needs to be consulted to determine if the authentication handler should actually do anything. Second is that the value associated with the AuthName directive can't be determined either, something which may influence against which database authentication should be done. Thus first lot of changes that need to be made are that req object needs to have two new methods called get_auth_type() and get_auth_name(). These will map to the Apache API functions called ap_auth_type() and ap_auth_name(). Note that ap_auth_type() is returning a different value to req.ap_auth_type. With those two functions, authentication handler can then be written as: def authenhandler(req): if req.get_auth_type() != Python-Basic-DBM: return apache.DECLINED realm = req.get_auth_name() # Do all the processing of Authorization header and # validate user etc. If not okay, return appropriate error # status. If okay, keep going. req.user = ... from header req.ap_auth_type = Python-Basic-DBM return apache.OK As well as returning apache.OK, convention is to set req.user and req.ap_auth_type. This is where the final problem occurs. That is that req.ap_auth_type is read only and cannot actually be set as necessary. Thus in addition to req.get_auth_type(), req.get_auth_name(), need to make req.ap_auth_type writable. Having made these changes it would then actually be possible to write authentication handlers correctly, ie., whereby they correctly look at AuthType etc to see whether they should be applied. -- This message is
[jira] Resolved: (MODPYTHON-139) Running make clean/distclean doesn't clean up test directory.
[ http://issues.apache.org/jira/browse/MODPYTHON-139?page=all ] Jim Gallacher resolved MODPYTHON-139: - Fix Version: 3.3 Resolution: Fixed Running make clean/distclean doesn't clean up test directory. - Key: MODPYTHON-139 URL: http://issues.apache.org/jira/browse/MODPYTHON-139 Project: mod_python Type: Bug Components: core Versions: 3.3 Reporter: Graham Dumpleton Assignee: Jim Gallacher Fix For: 3.3 Even after running a distclean, the following files are left in test directory. ? test/testconf.pyc ? test/httpdconf.pyc ? test/Makefile ? test/htdocs/dummymodule.pyc ? test/htdocs/cgitest.pyc ? test/htdocs/tests.pyc Should be addressed as part of test suite rewrite. -- 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] Commented: (MODPYTHON-104) Allow Python code callouts with mod_include (SSI).
[
http://issues.apache.org/jira/browse/MODPYTHON-104?page=comments#action_12370851
]
Jim Gallacher commented on MODPYTHON-104:
-
Comparing the current version with grahamd_20060226_MP104_1.diff, it looks
like some of the apache 2.2 code got copied over into the section for apache
2.0. Fix is attached as MP104_20060317_jgallacher_1.diff.
-SSI_CREATE_ERROR_BUCKET(ctx, f, bb);
+CREATE_ERROR_BUCKET(ctx, tmp_buck, head_ptr, *inserted_head);
+release_interpreter();
I still haven't reviewed the rest of the code, but unit tests passed once the
patch is applied.
Allow Python code callouts with mod_include (SSI).
--
Key: MODPYTHON-104
URL: http://issues.apache.org/jira/browse/MODPYTHON-104
Project: mod_python
Type: New Feature
Components: core
Reporter: Graham Dumpleton
Assignee: Graham Dumpleton
Fix For: 3.3
Attachments: MP104_20060317_jgallacher_1.diff,
grahamd_20060126_1_mod_include.diff, grahamd_20060226_MP104_1.diff
The mod_include module supporting server side includes (SSI), provides a
means of registering new element tags which trigger callouts to other code in
separate Apache modules. This is used for example in mod_perl to allow Perl
language code to be used with server side includes:
!--#perl sub=MySSI::remote_host --
!--#perl arg=Hello arg=SSI arg=World
sub=sub {
my($r, @args) = @_;
print qq(@args);
}
--
An equivalent feature for Python was previously asked about on the mailing
list back in 2004:
http://www.modpython.org/pipermail/mod_python/2004-January/014832.html
Since it seems entirely reasonable that such integration of mod_python and
mod_include would be possible, thought it would be good to log it as a
possible new feature.
Because of SSI's support for basic conditionals, includes and other callout
mechanisms, would be a good quick and dirty way of doing templating without
having to resort to PSP, or other high level templating systems.
--
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-104) Allow Python code callouts with mod_include (SSI).
[ http://issues.apache.org/jira/browse/MODPYTHON-104?page=all ]
Jim Gallacher updated MODPYTHON-104:
Attachment: MP104_20060317_jgallacher_1.diff
Fixes SSI_CREATE_ERROR_BUCKET problem for apache 2.0
Allow Python code callouts with mod_include (SSI).
--
Key: MODPYTHON-104
URL: http://issues.apache.org/jira/browse/MODPYTHON-104
Project: mod_python
Type: New Feature
Components: core
Reporter: Graham Dumpleton
Assignee: Graham Dumpleton
Fix For: 3.3
Attachments: MP104_20060317_jgallacher_1.diff,
grahamd_20060126_1_mod_include.diff, grahamd_20060226_MP104_1.diff
The mod_include module supporting server side includes (SSI), provides a
means of registering new element tags which trigger callouts to other code in
separate Apache modules. This is used for example in mod_perl to allow Perl
language code to be used with server side includes:
!--#perl sub=MySSI::remote_host --
!--#perl arg=Hello arg=SSI arg=World
sub=sub {
my($r, @args) = @_;
print qq(@args);
}
--
An equivalent feature for Python was previously asked about on the mailing
list back in 2004:
http://www.modpython.org/pipermail/mod_python/2004-January/014832.html
Since it seems entirely reasonable that such integration of mod_python and
mod_include would be possible, thought it would be good to log it as a
possible new feature.
Because of SSI's support for basic conditionals, includes and other callout
mechanisms, would be a good quick and dirty way of doing templating without
having to resort to PSP, or other high level templating systems.
--
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] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12370996 ] Jim Gallacher commented on MODPYTHON-93: I was checking the documentation with respect to this patch and I noticed a couple of things. The FieldStorage constructor has 2 undocumented parameters, file_callback=None, field_callback=None. These were added in r160259 as part of Barry Pearce's fix for MODPYTHON-40. In the same patch, the make_file and make_field methods were added. These allow FieldStorage to be subclassed and provide an alternative to using the callbacks. In Mike's modpython325_util_py_dict.patch, the make_field and make_file methods have be removed, with the reasoning that the callbacks should be sufficient for controlling the upload. We never had a discussion of the merits of the 2 approaches - subclassing vs passing the callbacks in the FieldStorage constructor. Should we perhaps allow both, and reinstate make_field and make_file, or are the callbacks sufficient? Further infomation on the callbacks, including some nice examples, can be found in the python-dev archives. See http://article.gmane.org/gmane.comp.apache.mod-python.devel/760 I'll update the docs as part of the fix for this issue. Improve util.FieldStorage efficiency Key: MODPYTHON-93 URL: http://issues.apache.org/jira/browse/MODPYTHON-93 Project: mod_python Type: Improvement Components: core Versions: 3.2.7 Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor Fix For: 3.3 Attachments: modpython325_util_py_dict.patch Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour. This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created. Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto. -- 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-93) Improve util.FieldStorage efficiency
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=all ] Jim Gallacher resolved MODPYTHON-93: Resolution: Fixed Improve util.FieldStorage efficiency Key: MODPYTHON-93 URL: http://issues.apache.org/jira/browse/MODPYTHON-93 Project: mod_python Type: Improvement Components: core Versions: 3.2.7 Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor Fix For: 3.3 Attachments: modpython325_util_py_dict.patch Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour. This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created. Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto. -- 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] Created: (MODPYTHON-158) Improve Installation / Troubleshooting section in documentation
Improve Installation / Troubleshooting section in documentation --- Key: MODPYTHON-158 URL: http://issues.apache.org/jira/browse/MODPYTHON-158 Project: mod_python Type: Improvement Components: documentation Versions: 3.3 Environment: All Reporter: Jim Gallacher Priority: Minor Some of the more commonly asked questions asked on the mailing list relate to mod_python configuration issues that are not currently covered in the documentation. Apache can't load mod_python.so - This more common problem on Windows, but can occur on other platforms. A typical apache error message looks like this: Syntax error on line 173 of C:/Program Files/Apache Group/Apache2/conf/httpd.conf: Cannot load C:/Program Files/Apache Group/Apache2/modules/mod_python.so into server: The specified module could not be found. On Windows this may indicate a problem with missing D Nicolas offered the following as an explanation on Windows: One of the possible cause of your problem is that Apache does find mod_python.so but not one of the DLL it relies on. Unfortunately the error reporting in this case is quite scarce and misguiding. The candidates missing DLLs are python24.dll and the Microsoft Runtime DLLS (normally msvcr71.dll and msvcp71.dll). Make sure that your Python directory and the runtime DLLs can be found on your PATH. The runtime DLLs are normaly copied in your Python directory, so putting the Python directory on your PATH variable should do the trick. Also, make sure that the user which is running Apache has its PATH variable properly set. The best way to do this is to define it at the system-wide level, but logging it under the user and defining the variable at the user level is also possible. Apache can't load mod_python.so - undefined symbol --- This may look similar to the first example, but indicates a deeper problem. Typical error message: httpd: Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/mod_python.so into server: /usr/local/apache2/modules/mod_python.so: undefined symbol: apr_sockaddr_port_get This error could indicate an actual bug in mod_python, or a mismatch between the Apache version used to compile mod_python versus the one being used to run it. I'm not sure there is an easy answer, but we should offer some initial troubleshooting suggestions. make_obcallback: could not import mod_python.apache -- This one seems to occur on all platforms with similar frequency, and is usually related to having python multiple versions on the same system. Typical error message: [Sun Apr 09 14:03:46 2006] [error] make_obcallback: could not import mod_python.apache.\n [Sun Apr 09 14:03:46 2006] [error] python_handler: no interpreter callback found. [Sun Apr 09 14:03:46 2006] [error] [client 192.168.2.100] python_handler: Can't get/create interpreter., referer: http://localhost/mptest.py The solution is to adjust that PATH apache uses so it finds the correct python version. This will be platform specific. -- 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] Created: (MODPYTHON-168) psp_parser fails when CR is used as a line terminator
psp_parser fails when CR is used as a line terminator
--
Key: MODPYTHON-168
URL: http://issues.apache.org/jira/browse/MODPYTHON-168
Project: mod_python
Type: Bug
Components: core
Versions: 3.3
Environment: Mac OS X using older GoLive editor
Reporter: Jim Gallacher
Assigned to: Jim Gallacher
Priority: Minor
As reported by Jeff Zelt:
On Mac OS X, make sure that your HTML files are terminated by :
a line feed (ascii 10) and NOT a carriage return (ascii 13).
PSP does *not* like lines terminated by only a carriage return.
The problem was that I was using Adobe GoLive to edit my web pages and to
insert the python code in the page (I am talking about the source view, not the
WYSIWYG/Layout view). My version of GoLive is a little old and still prefers
to write files with carriage return line endings. This was the default for the
Mac OS before Mac OS X. Everything *looks* OK in the GoLive editor and it also
looked OK in the other editors I chose to check the code (other editors would
have tipped me off, but I did not use one of those).
However, it seems that the PSP engine, or whatever you want to call it, does
not treat carriage returns as line endings, and therefore chokes badly when
encountering code written this way.
GoLive has a menu item where you can select the desired line terminator. I
selected Unix (LF). This made no visible change to the document when viewed
in GoLive, but then suddenly the % ... % PSP parts of the document worked
perfectly.
I've confirmed that psp_parser.l expects lines of python code to be terminated
with: \r\n | \n | % so the fix should be a one liner.
Index: src/psp_parser.l
===
--- src/psp_parser.l(revision 398185)
+++ src/psp_parser.l(working copy)
@@ -119,7 +119,7 @@
}
}
-PYCODE\r\n|\n {
+PYCODE\r\n|\n|\r {
psp_string_appendc(PSP_PG(pycode), '\n');
PSP_PG(seen_newline) = 1;
--
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] Created: (MODPYTHON-173) DbmSession creates world readable db file
DbmSession creates world readable db file - Key: MODPYTHON-173 URL: http://issues.apache.org/jira/browse/MODPYTHON-173 Project: mod_python Type: Bug Components: session Versions: 3.2.8 Reporter: Jim Gallacher Assigned to: Jim Gallacher Fix For: 3.2.x DbmSession uses the default mode when creating the db file. As a result the file is world readable, which may be undesirable where sensitive informaiton is stored in the session. Currently the users are required to chmod the file manually. This can be fixed by using the option mode argument when the file is opened. Quoting from the python anydbm documentation: open( filename[, flag[, mode]] The optional mode argument is the Unix mode of the file, used only when the database has to be created. It defaults to octal 0666 (and will be modified by the prevailing umask). -- 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] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12417405 ] Jim Gallacher commented on MODPYTHON-93: As part of the improvments to FieldStorage, the Field class __init__ method was changed in trunk (3.3-dev) and backported to branches/3.2.x. Although the documentation states that the Field class is for internal use by FieldStorage, some software applications create Field instances directly. This change in the __init__ signature causes those applications to fail. Breaking compatibility may be acceptable for a minor version increment (3.2 3.2) but is undesirable for a patch release (3.2.8 3.2.9). Changing the Field class to be both forward and backward compatible wil not be difficult. As such I'll commit a fix to branches/3.2.x in time for a 3.2.9 release. Improve util.FieldStorage efficiency Key: MODPYTHON-93 URL: http://issues.apache.org/jira/browse/MODPYTHON-93 Project: mod_python Type: Improvement Components: core Versions: 3.2.7 Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor Fix For: 3.3 Attachments: modpython325_util_py_dict.patch Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour. This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created. Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto. -- 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-84) req.sendfile(filename) sends an incorrect number of bytes when filename is a symlink
[ http://issues.apache.org/jira/browse/MODPYTHON-84?page=all ] Jim Gallacher resolved MODPYTHON-84: Fix Version: 3.2.8 (was: 3.2.7) Resolution: Fixed req.sendfile(filename) sends an incorrect number of bytes when filename is a symlink Key: MODPYTHON-84 URL: http://issues.apache.org/jira/browse/MODPYTHON-84 Project: mod_python Type: Bug Components: core Versions: 3.1.3, 3.2.7, 3.1.4 Reporter: Jim Gallacher Assignee: Graham Dumpleton Fix For: 3.2.8 This issue was reported by Wim Heirman on the mod_python list: When req.sendfile(filename) is called where filename is a symbolic link, only part of the file is sent to the client (as many bytes as there are characters in the symlink's file reference, so for a symlink pointing to '../index.html' returns the first 13 bytes of the correct file). Wim suggested changing APR_READ to APR_FINFO_NORM in the apr_stat call in req_sendfile(). -- 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] Reopened: (MODPYTHON-93) Improve util.FieldStorage efficiency
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=all ] Jim Gallacher reopened MODPYTHON-93: Reopened issue due to problems experienced by some applications such as Trac. We'll need to re-examine the code committed to make sure that FieldStorage behaves properly as a dictionary-like object. Improve util.FieldStorage efficiency Key: MODPYTHON-93 URL: http://issues.apache.org/jira/browse/MODPYTHON-93 Project: mod_python Type: Improvement Components: core Versions: 3.2.7 Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor Fix For: 3.3 Attachments: modpython325_util_py_dict.patch Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour. This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created. Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto. -- 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] Created: (MODPYTHON-179) req.readlines(sizehint) does not work correctly
req.readlines(sizehint) does not work correctly
---
Key: MODPYTHON-179
URL: http://issues.apache.org/jira/browse/MODPYTHON-179
Project: mod_python
Type: Bug
Components: core
Versions: 3.2.8
Environment: All
Reporter: Jim Gallacher
Assigned to: Jim Gallacher
Priority: Minor
A bug in req_readlines(sizehint) in requestobject.c causes output to be
returned prematurely for any value of the optional sizehint argument.
The faulty bit of code is:
line = req_readline(self, rlargs);
while (line (PyString_Size(line)0)) {
PyList_Append(result, line);
size += PyString_Size(line);
if ((sizehint != -1) (size = size))
break;
line = req_readline(self, args);
}
Since (size = size) will always be true, reading the input stream will end
prematurely for any value of sizehint != -1.
This code will fix the problem.
--- requestobject.c (revision 417294)
+++ requestobject.c (working copy)
@@ -1154,7 +1154,7 @@
while (line (PyString_Size(line)0)) {
PyList_Append(result, line);
size += PyString_Size(line);
-if ((sizehint != -1) (size = size))
+if ((sizehint != -1) (size = sizehint))
break;
line = req_readline(self, args);
}
Once that is fixed the documentation needs to be revised, as it does not
accurately reflect the behaviour of the code.
Currently the docs are:
Reads all or up to sizehint bytes of lines using readline and returns a list
of the lines read.
whereas the code can read beyond sizehint. The total read could actually be
sizehint + len(line) where line is the last line read.
--
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-168) psp_parser fails when CR is used as a line terminator
[ http://issues.apache.org/jira/browse/MODPYTHON-168?page=all ]
Jim Gallacher resolved MODPYTHON-168.
-
Fix Version/s: 3.3
Resolution: Fixed
psp_parser fails when CR is used as a line terminator
-
Key: MODPYTHON-168
URL: http://issues.apache.org/jira/browse/MODPYTHON-168
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.3
Environment: Mac OS X using older GoLive editor
Reporter: Jim Gallacher
Assigned To: Jim Gallacher
Priority: Minor
Fix For: 3.3
As reported by Jeff Zelt:
On Mac OS X, make sure that your HTML files are terminated by :
a line feed (ascii 10) and NOT a carriage return (ascii 13).
PSP does *not* like lines terminated by only a carriage return.
The problem was that I was using Adobe GoLive to edit my web pages and to
insert the python code in the page (I am talking about the source view, not
the WYSIWYG/Layout view). My version of GoLive is a little old and still
prefers to write files with carriage return line endings. This was the
default for the Mac OS before Mac OS X. Everything *looks* OK in the GoLive
editor and it also looked OK in the other editors I chose to check the code
(other editors would have tipped me off, but I did not use one of those).
However, it seems that the PSP engine, or whatever you want to call it, does
not treat carriage returns as line endings, and therefore chokes badly when
encountering code written this way.
GoLive has a menu item where you can select the desired line terminator. I
selected Unix (LF). This made no visible change to the document when
viewed in GoLive, but then suddenly the % ... % PSP parts of the document
worked perfectly.
I've confirmed that psp_parser.l expects lines of python code to be
terminated with: \r\n | \n | % so the fix should be a one liner.
Index: src/psp_parser.l
===
--- src/psp_parser.l (revision 398185)
+++ src/psp_parser.l (working copy)
@@ -119,7 +119,7 @@
}
}
-PYCODE\r\n|\n {
+PYCODE\r\n|\n|\r {
psp_string_appendc(PSP_PG(pycode), '\n');
PSP_PG(seen_newline) = 1;
--
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-185) _psp.parsestring doesn't check for empty values
[ http://issues.apache.org/jira/browse/MODPYTHON-185?page=all ] Jim Gallacher resolved MODPYTHON-185. - Fix Version/s: 3.3 Resolution: Fixed _psp.parsestring doesn't check for empty values --- Key: MODPYTHON-185 URL: http://issues.apache.org/jira/browse/MODPYTHON-185 Project: mod_python Issue Type: Bug Components: psp Environment: All Reporter: Thomas Hervé Assigned To: Jim Gallacher Priority: Minor Fix For: 3.3 Attachments: _pspmodule.diff The function _psp_module_parsestring of _pspmodule.c doesn't check the value of parser-pycode.blob when calling PyString_FromString (whereas it's done in _psp_module_parse). When called with an empty string it can cause a segfault (blob is NULL and PyString_FromString doesn't check for NULL value). I attach a simple diff correcting the problem. -- 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] Commented: (MODPYTHON-187) Hang on subscripted access to request.subprocess_env.
[
http://issues.apache.org/jira/browse/MODPYTHON-187?page=comments#action_12431099
]
Jim Gallacher commented on MODPYTHON-187:
-
Confirmed for Apache 2.0.55 mpm-worker (Linux Ubuntu 6.0.6), execpt I get a
segfault rather than a hang.
Note that the Post Read Request phase occurs before apache translates the URI
to a filename. request.subprocess_env.get('SCRIPT_FILENAME') seems to do the
right thing by returning None.
Hang on subscripted access to request.subprocess_env.
-
Key: MODPYTHON-187
URL: http://issues.apache.org/jira/browse/MODPYTHON-187
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10
Environment: Apache: 2.0.59
ModPython: 3.2.10
Python: 2.4
OS: Windows Server 2003
Reporter: Alan Kennedy
When subscripted access is used to access variable 'SCRIPT_FILENAME' in the
request.subprocess_env table/mapping, the code hangs.
The following snippet illustrates the problem.
# -=-=-=-=-=-=
def postreadrequesthandler(request):
request.add_common_vars()
value = request.subprocess_env['SCRIPT_FILENAME']# This hangs
# value = request.subprocess_env.get('SCRIPT_FILENAME')# This works
return apache.OK
# -=-=-=-=-=-=
The strange thing is that the .get() access works fine: only the subscript
hangs?
If anyone is wondering about a use-case, I don't actually have one. I was
just iterating over the contents of the request.subprocess_env using a for
loop (code below), and found that the code hung when accessing
'SCRIPT_FILENAME', and not for any other variable.
# -=-=-=
request.add_common_vars()
d = {}
for sek in request.subprocess_env.keys():
d[sek] = request.subprocess_env[sek]
# -=-=-=
--
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-187) Hang on subscripted access to request.subprocess_env.
[ http://issues.apache.org/jira/browse/MODPYTHON-187?page=all ]
Jim Gallacher updated MODPYTHON-187:
Attachment: MP187-2006-08-28-jgallacher-1.diff
I hope I have the reference count right!
Hang on subscripted access to request.subprocess_env.
-
Key: MODPYTHON-187
URL: http://issues.apache.org/jira/browse/MODPYTHON-187
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10
Environment: Apache: 2.0.59
ModPython: 3.2.10
Python: 2.4
OS: Windows Server 2003
Reporter: Alan Kennedy
Attachments: MP187-2006-08-28-jgallacher-1.diff
When subscripted access is used to access variable 'SCRIPT_FILENAME' in the
request.subprocess_env table/mapping, the code hangs.
The following snippet illustrates the problem.
# -=-=-=-=-=-=
def postreadrequesthandler(request):
request.add_common_vars()
value = request.subprocess_env['SCRIPT_FILENAME']# This hangs
# value = request.subprocess_env.get('SCRIPT_FILENAME')# This works
return apache.OK
# -=-=-=-=-=-=
The strange thing is that the .get() access works fine: only the subscript
hangs?
If anyone is wondering about a use-case, I don't actually have one. I was
just iterating over the contents of the request.subprocess_env using a for
loop (code below), and found that the code hung when accessing
'SCRIPT_FILENAME', and not for any other variable.
# -=-=-=
request.add_common_vars()
d = {}
for sek in request.subprocess_env.keys():
d[sek] = request.subprocess_env[sek]
# -=-=-=
--
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-182) Memory leak in request readline()
[ http://issues.apache.org/jira/browse/MODPYTHON-182?page=all ]
Jim Gallacher resolved MODPYTHON-182.
-
Resolution: Fixed
Memory leak in request readline()
-
Key: MODPYTHON-182
URL: http://issues.apache.org/jira/browse/MODPYTHON-182
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10, 3.3, 3.2.x
Environment: Apache 2.0.55 mpm-worker
Reporter: Jim Gallacher
Assigned To: Jim Gallacher
Fix For: 3.3
There is at least one memory leak request.readline(). I'm currently auditing
the code so there may well be others.
I think the leak will only occur when the request body is incompletely read
with readline, which is likely an unusual corner case. The following
demostrates the leak:
Consider a request body consisting of:
'\n'.join([ 'a'*100 for i in xrange(0, 100) ])
and using this handler:
def handler(req):
# Handler reads 20 lines but request contains 100 lines.
# Since the body is not completely read, the buffer allocated
# in requestobject.c req_readline is never freed.
req.content_type = 'text/plain'
count = 0
for i in range(0, 20):
line = req.readline()
count += 1
req.write('ok readline_partial: %d lines read' % count)
return apache.OK
With this test setup I'm seeing a leak of approx 10k bytes per request.
--
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-53) Show link for subversion and JIRA on www.mod_python website
[ http://issues.apache.org/jira/browse/MODPYTHON-53?page=all ] Jim Gallacher resolved MODPYTHON-53. Resolution: Fixed Show link for subversion and JIRA on www.mod_python website --- Key: MODPYTHON-53 URL: http://issues.apache.org/jira/browse/MODPYTHON-53 Project: mod_python Issue Type: Wish Components: documentation Reporter: Jim Gallacher Priority: Trivial The mod_python website still has links to CVS repository, instead of subversion. Also, it would be nice if there was a link to JIRA. And if you are making changes to the website, might as well add a link to the python-dev list archive at gmane. http://dir.gmane.org/gmane.comp.apache.mod-python.devel -- 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-201) ReportError in importer.py raises an exception for mal-formed psp
[ http://issues.apache.org/jira/browse/MODPYTHON-201?page=all ]
Jim Gallacher closed MODPYTHON-201.
---
Fix Version/s: 3.3
Resolution: Fixed
Already fixed in a more recent commit.
ReportError in importer.py raises an exception for mal-formed psp
-
Key: MODPYTHON-201
URL: http://issues.apache.org/jira/browse/MODPYTHON-201
Project: mod_python
Issue Type: Bug
Components: importer
Affects Versions: 3.3
Environment: 3.3.0-dev-20061029
Reporter: Jim Gallacher
Priority: Blocker
Fix For: 3.3
Mal formed psp causes an exception in importer.py ReportError
The following psp contains a syntax error, and generates an exception as
expected, causing importer.ReportError to be called.
test.psp
-
%
req.write('x'
%
There is bug in ReportError however that raises an exception, and a 500
Internal Server Error is sent to the client.
apache error_log
--
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] req.write(
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] ^
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] SyntaxError: invalid
syntax
Traceback (most recent call last):
File /usr/lib/python2.4/site-packages/mod_python/importer.py, line 1797,
in ReportError
stime = time.asctime(time.localtime(modules.stime))
AttributeError: '_module_cache' object has no attribute 'stime'
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] python_handler:
Dispatch() returned non-integer.
I'm not sure if this is a simple bug in ReportError, or indicates a deeper
problem with cache mechanism in the importer.
--
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] Commented: (MODPYTHON-172) Memory leak with util.fieldstorage using mod_python 3.2.8 on apache 2.0.55
[ http://issues.apache.org/jira/browse/MODPYTHON-172?page=comments#action_12447658 ] Jim Gallacher commented on MODPYTHON-172: - [[ Old comment, sent by email on Fri, 07 Jul 2006 21:26:01 -0400 ]] I've been working through the PyList_Append instances and noticed the cfgtree_walk and req_readlines issues as well. I've confirmed that cfgtree_walk does indeed leak. I haven't tested req_readlines but I can't see why it wouldn't leak. Can you spot the other bug in req_readlines? Hint: (size = size) will always be true. ;) Once that is fixed I think we need to alter the docs for req.readlines() as I'm not sure the description for sizehint accurately reflects the way it works. Jim Memory leak with util.fieldstorage using mod_python 3.2.8 on apache 2.0.55 -- Key: MODPYTHON-172 URL: http://issues.apache.org/jira/browse/MODPYTHON-172 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.8 Environment: Win32 XP SP1 / SP2 Apache 2.0.55 installed from binary (.MSI) Python 2.4.2 or 2.4.3installed from binary from www.python.org Reporter: Laurent Blanquet Fix For: 3.3, 3.2.10 I encounter memory leaks [~ 16 K per request) using the configuration described below. = Python configuration from Httpd.conf: = Alias /python/ d:/python24/B2B/ Directory d:/python24/B2B AddHandler mod_python .py PythonHandler pyHandlerHTTP PythonDebug On /Directory = Test handler - pyHandlerHTTP.py : = import mod_python from mod_python import util def handler(req): #Removing this line solves the problem. F=util.FieldStorage( req ) return mod_python.apache.OK = HTTP Request (dump using TCPWATCH): = POST http://localhost:80/python/Alertes.py HTTP/1.0 Content-Type: multipart/form-data; boundary=061006144341906 Content-Length: 209 Proxy-Connection: keep-alive Host: www.tx2-localhost Accept: text/html, */* User-Agent: Mozilla/3.0 (compatible; Indy Library) Proxy-Authorization: Basic Og== --061006144341906 Content-Disposition: form-data; name=TYPE LAST_ALERTS --061006144341906 Content-Disposition: form-data; name=FILEAGE 180 --061006144341906 -- 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] Commented: (MODPYTHON-184) Memory leak apache.table()
[
http://issues.apache.org/jira/browse/MODPYTHON-184?page=comments#action_12447666
]
Jim Gallacher commented on MODPYTHON-184:
-
[[ Old comment, sent by email on Wed, 16 Aug 2006 17:44:21 -0400 ]]
Actually I don't think apr_pool_destroy() in table_dealloc is actually
destroying the pool. I've been poking around in the code and there is
something odd going on here.
I tried registering a cleanup in MpTable_New() using:
apr_pool_cleanup_register(t-pool,
pool cleanup called,
cleanup_test,
apr_pool_cleaunp_null);
The cleanup_test callback just logs the pool cleanup called message to
a file.
apr_pool_destroy() is getting called in table_dealloc, but cleanup_test
never gets called which indicates that the pool is *not* being
destroyed, and hence our memory leak.
I tried your trick of immediately calling apr_pool_destroy in
MpTable_New(), and cleanup_test does get called there.
So, the big question is... why is the pool not being destroyed?
Can anyone offer some insight here?
The attached diff is for trunk if anyone wants to play around with it.
Jim
Index: tableobject.c
===
--- tableobject.c (revision 431994)
+++ tableobject.c (working copy)
@@ -59,6 +59,19 @@
return (PyObject *)result;
}
+
+
+apr_status_t cleanup_test(void *msg)
+{
+FILE *f;
+f = fopen(/tmp/debug_table.log, a+);
+fprintf(f, %s\n, (char *)msg);
+fclose(f);
+
+return 0;
+}
+
+
/**
** MpTable_New
**
@@ -78,6 +91,8 @@
tableobject *t;
apr_pool_t *p;
+cleanup_test(MpTable_New() called);
+
/* XXX need second arg abort function to report mem error */
apr_pool_create_ex(p, NULL, NULL, NULL);
@@ -86,7 +101,12 @@
/* remember the pointer to our own pool */
t-pool = p;
+apr_pool_cleanup_register(p, pool cleanup called, cleanup_test,
apr_pool_cleanup_null);
+/* Uncomment this to test that cleanup_test is getting called correctly.
+apr_pool_destroy(t-pool);
+*/
+
return (PyObject *)t;
}
@@ -99,10 +119,13 @@
static void table_dealloc(register tableobject *self)
{
+cleanup_test(table_dealloc:);
if (MpTable_Check(self)) {
-if (self-pool)
+if (self-pool) {
+cleanup_test( preparing to destroy the pool);
apr_pool_destroy(self-pool);
+}
PyObject_Del(self);
}
else
Memory leak apache.table()
--
Key: MODPYTHON-184
URL: http://issues.apache.org/jira/browse/MODPYTHON-184
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.3, 3.2.10
Reporter: Jim Gallacher
Assigned To: Jim Gallacher
Fix For: 3.3
Attachments: MP184-2006-08-25-grahamd-1.diff
There is a memory leak in apache.table().
from mod_python import apache
def handler(req):
req.content_type = 'text/plain'
t = apache.make_table()
req.write('ok table:')
return apache.OK
Using mpm-worker with StartServers 2, and 2 requests results in memory
consumption going from 1.2% to 9.3% per process. (ie approx 8k per request)
This will have an impact on FieldStorage which makes use of
apache.make_table(), which is the deprecated name for apache.table()
--
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] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
[ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12449192 ] Jim Gallacher commented on MODPYTHON-202: - We seem to be going pretty far down the road with PythonOption and our new namespace, so I'm inclined to stick with that, unless there is some sort of performance implication. Jim Allow mechanism used by global mutex locks to be specified. --- Key: MODPYTHON-202 URL: http://issues.apache.org/jira/browse/MODPYTHON-202 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton When using experimental Apache ITK MPM, described at: http://home.samfundet.no/~sesse/mpm-itk/ global mutex locks will fail if Apache used semaphores because requests against different virtual hosts run as different users and user will not have permission to access the semaphore to lock it. See: http://www.modpython.org/pipermail/mod_python/2006-November/022536.html for original mailing list post about this from Sam Morris. A suggested fix of finding a specific mechanism that works rather than default used by Apache, seems to work: http://www.modpython.org/pipermail/mod_python/2006-November/022537.html http://www.modpython.org/pipermail/mod_python/2006-November/022538.html http://www.modpython.org/pipermail/mod_python/2006-November/022539.html If available MPMs with such constraints are going to appear, may make sense to have an option to configure which allows one to override at compile time the default mechanism used for global mutex locks so that it can be made to match what may be required for a specific MPM that Apache is compiled to use. -- 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-19) Add a section about security in the documentation
[ http://issues.apache.org/jira/browse/MODPYTHON-19?page=all ] Jim Gallacher resolved MODPYTHON-19. Fix Version/s: 3.3 Resolution: Fixed CategorySecurity and SecurityConsiderations sections have been added to the mod_python wiki. Links to those pages have been added to the source documentation. Add a section about security in the documentation - Key: MODPYTHON-19 URL: http://issues.apache.org/jira/browse/MODPYTHON-19 Project: mod_python Issue Type: Task Components: documentation Affects Versions: 3.1.3 Reporter: Nicolas Lehuen Assigned To: Jim Gallacher Fix For: 3.3 A good beginning is this thread : http://www.modpython.org/pipermail/mod_python/2005-February/017297.html -- 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
