[jira] Closed: (MODPYTHON-103) Implement req.add_output_filter().
[
https://issues.apache.org/jira/browse/MODPYTHON-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-103.
--
> Implement req.add_output_filter().
> --
>
> Key: MODPYTHON-103
> URL: https://issues.apache.org/jira/browse/MODPYTHON-103
> Project: mod_python
> Issue Type: New Feature
> Components: core
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
> Attachments: grahamd_20060108_1_requestobject.c.diff,
> grahamd_20060108_2_multiple.diff
>
>
> Add new member function to request object called "add_output_filter()". This
> would be a wrapper around the function "ap_add_output_filter()" and allow
> previously defined filters to be attached to the current request such that
> output can be filtered through them. For example:
> req.add_output_filter("INCLUDES")
> It would probably be necessary for any such call to be done prior to the
> first output being generated from the request handler.
> In addition to this member function, it may be necessary to also provide
> another member function called something like
> "req.add_python_output_filter()". This would be called something like:
> req.add_python_output_filter("module_name::filter_name",path)
> Ie., like "req.add_handler()" but no first argument for phase.
> This method would allow a specific Python filter handler function to be
> specified. This would be equivalent to using the PythonOutputFilter directive
> to first name a mod_python based filter handler function and then adding it
> as an output filter.
> # Main Apache config.
> PythonOutputFilter module_name::filter_name MYFILTER
> # Handler code.
> req.add_output_filter("MYFILTER")
> Note that the PythonOutputFilter directive can only be used in the main
> Apache configuration file, it cannot be used in a .htaccess file. Whether it
> could be made to work in a .htaccess file in some way needs to be
> investigated. In mod_perl their equivlent seems to allow it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-101) If target handler found but evaluates false, there should still be an error if not silent.
[
https://issues.apache.org/jira/browse/MODPYTHON-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-101.
--
> If target handler found but evaluates false, there should still be an error
> if not silent.
> --
>
> Key: MODPYTHON-101
> URL: https://issues.apache.org/jira/browse/MODPYTHON-101
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.4, 3.2.7
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> If one specifies PythonHandler directive and the target is mistakenly set to
> be something like:
> handler = 0
> handler = None
> handler = False
> handler = []
> handler = {}
> no error is raised.
> As comparison, if one has:
> handler = 1
> you get an error:
> Traceback (most recent call last):
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py",
> line 309, in HandlerDispatch
> result = object(req)
> TypeError: 'int' object is not callable
> This is because if the target in any way evaluates to false, no attempt is
> made to execute it, but at the same time if the silent flag is not set no
> error is raised either.
> In the case of HandlerDispatch in apache.py, the code currently is:
> # find the object
> object = resolve_object(module, object_str,
> arg=req, silent=hlist.silent)
>
> if object:
>
> # call the object
>
> elif hlist.silent:
> result = DECLINED
>
> It would make more sense that if hlist.silent is not set, that the object,
> whatever it may be should be called. This would ensure that any error
> response is always generated when it can be.
> Thus, instead of just:
> if object:
> it should really be:
> if not hlist.silent or object:
> In the case of ConnectionDispatch() and FilterDispatch(), because silent is
> fixed to "0" in those cases, there should not even be a check of whether
> object evaluates true, it should just be called regardless.
> Thus instead of:
> if object:
> # call the object
> if config.has_key("PythonEnablePdb"):
> result = pdb.runcall(object, conn)
> else:
> result = object(conn)
> it should just be:
> # call the object:
> if config.has_key("PythonEnablePdb"):
> result = pdb.runcall(object, conn)
> else:
> result = object(conn)
> Indent level of following assertion clause in case of ConnectionDispatch()
> and call to filter.flush() in FilterDispatcher() should also be shifted out
> as well as appropriate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-100) raise apache.SERVER_RETURN, apache.OK aborts handlers.
[
https://issues.apache.org/jira/browse/MODPYTHON-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-100.
--
> raise apache.SERVER_RETURN, apache.OK aborts handlers.
> --
>
> Key: MODPYTHON-100
> URL: https://issues.apache.org/jira/browse/MODPYTHON-100
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.4, 3.2.7
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> If multiple handlers are defined for a phase and a handler which isn't the
> last one, rather than returning the value apache.OK as the result, raises the
> apache.SERVER_RETURN exception with apache.OK as argument, then processing of
> subsequent handlers in that phase are being aborted.
> Ie., consider the example with .htaccess file of:
> SetHandler mod_python
> PythonHandler example::handler_1
> PythonHandler example::handler_2
> and example.py of:
> from mod_python import apache
> def handler_1(req):
> apache.log_error("handler_1")
> req.content_type = 'text/plain'
> req.write("HELLO")
> # return apache.OK
> raise apache.SERVER_RETURN, apache.OK
> def handler_2(req):
> apache.log_error("handler_2")
> return apache.OK
> The expectation would be that returning the value apache.OK from the handler
> function and raising an exception of type apache.SERVER_RETURN with argument
> apache.OK would be equivalent, but they aren't. When the exception is being
> raised, handler_2() function is never executed.
> It would seem more sensible that they are equivalent as there are other
> specific status values that can be used in the case that one wants to prevent
> further handlers in the phase from being executed. For example, as
> appropriate, one of:
> req.status = apache.HTTP_OK
> raise apache.SERVER_RETURN, apache.DONE
> or:
> raise apache.SERVER_RETURN, (apache.DONE,apache.HTTP_OK)
> or:
> raise apache.SERVER_RETURN, apache.DECLINED
> To fix this, the apache.SERVER_RETURN exception should be processed within
> the processing loop for each handler, rather than being handled outside of
> the loop. The status as returned by the exception should be translated to
> look like it was returned by the handler and dealt with as for other status
> values returned explicitly.
> No patch, perhaps wait for my rewrite of the importer for mod_python 3.3 as
> already addresses this issue. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-94) Calling APR optional functions provided by mod_ssl
[ https://issues.apache.org/jira/browse/MODPYTHON-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-94. - > Calling APR optional functions provided by mod_ssl > -- > > Key: MODPYTHON-94 > URL: https://issues.apache.org/jira/browse/MODPYTHON-94 > Project: mod_python > Issue Type: New Feature > Components: core > Environment: Apache 2 >Reporter: Deron Meranda > Assigned To: Graham Dumpleton > Fix For: 3.3, 3.2.10 > > Attachments: modpython4.tex.patch, requestobject.c.patch > > > mod_python is not able to invoke APR Optional Functions. There are > some cases however where this could be of great benifit. > For example, consider writing an authentication or authorization handler > which needs to determine SSL properties (even if to just answer the > simple question: is the connection SSL encrypted). The normal way of > looking in the subprocess_env for SSL_* variables does not work in those > early handler phases because those variables are not set until the fixup > phase. > The mod_ssl module though does provide both a ssl_is_https() and > ssl_var_lookup() optional functions which can be used in earlier > phases. For example look at how mod_rewrite calls those; using > the APR_DECLARE_OPTIONAL_FN and APR_RETRIEVE_OPTIONAL_FN > macros. > I can see how it might be very hard to support optional functions in > general because of the C type linkage issue, but perhaps a select few > could be coded directly into mod_python. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-93) Improve util.FieldStorage efficiency
[ https://issues.apache.org/jira/browse/MODPYTHON-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-93. - > Improve util.FieldStorage efficiency > > > Key: MODPYTHON-93 > URL: https://issues.apache.org/jira/browse/MODPYTHON-93 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.2.7 >Reporter: Jim Gallacher > Assigned To: Graham Dumpleton >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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-90) Explicitly don't allow Pdb support to work if not ONE_PROCESS mode.
[
https://issues.apache.org/jira/browse/MODPYTHON-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-90.
-
This issue may have to be revisited as using -X option has same effect as
running -DONE_PROCESS -DNO_DETACH and would also allow debugging, but no
ONE_PROCESS option is set that can be checked for. You might even be able to
use -DDEBUG as well. Thus, at the moment, one has to redundantly add
-DONE_PROCESS to the -X option for this code change to work. No one has
complained yet though which suggests no one really uses it.
> Explicitly don't allow Pdb support to work if not ONE_PROCESS mode.
> ---
>
> Key: MODPYTHON-90
> URL: https://issues.apache.org/jira/browse/MODPYTHON-90
> Project: mod_python
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.3
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
>Priority: Minor
> Fix For: 3.3
>
>
> mod_python provides the PythonEnablePdb option for enabling of the Python
> debugger. For it to work properly though, it is necessary to start httpd from
> the command line with the -DONE_PROCESS option. If one doesn't do this though
> and enables PythonEnablePdb when Apache is running normally, any request to a
> URL for which the debugger is enabled will yield a 500 error. The details of
> the 500 error will be:
> Mod_python error: "PythonHandler mptest"
> Traceback (most recent call last):
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py",
> line 313, in HandlerDispatch
> assert (type(result) == type(int())), \
> AssertionError: Handler 'mptest' returned invalid return code.
> This error message isn't particularly helpful in understanding that the
> problem is that the debugger can't be run in this mode.
> To avoid this problem at the moment, all that can be done is for the user to
> know that their Apache configuration should actually say:
>
> PythonEnablePdb On
>
> This would mean they could leave the Apache configuration set the one way and
> not have to worry.
> What could instead be done in mod_python though is simply to ignore the
> PythonEnablePdb option and that it is set if Apache hasn't been run in
> ONE_PROCESS mode. Thus, presuming that MODPYTHON-89 has been implemented, the
> mod_python code in mod_python.apache in the number of places where it occurs,
> could say:
> # call the object
> if exists_config_define("ONE_PROCESS") and
> config.has_key("PythonEnablePdb"):
> result = pdb.runcall(object, conn)
> else:
> result = object(conn)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-91) Improve error message when "quit" run in pdb debugger.
[ https://issues.apache.org/jira/browse/MODPYTHON-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-91. - > Improve error message when "quit" run in pdb debugger. > -- > > Key: MODPYTHON-91 > URL: https://issues.apache.org/jira/browse/MODPYTHON-91 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.3 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton >Priority: Minor > Fix For: 3.3 > > > If one has enabled PythonEnablePdb and correctly running "httpd" with > -DONE_PROCESS option, in the debugger, if you run the "quit" command in the > debugger, you get back the result 500 error message reads as: > Mod_python error: "PythonHandler mptest" > Traceback (most recent call last): > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py", > line 313, in HandlerDispatch > assert (type(result) == type(int())), \ > AssertionError: Handler 'mptest' returned invalid return code. > It might be nice to have an error response which actually indicates in some > way that the debugger was explicitly quit for the request that was being > debugged. > The reason that the error above occurs now is that the debugger support uses > the call: > result = pdb.runcall(object, conn) > This ultimately executes bdb.Bdb.runcall(); > def runcall(self, func, *args): > self.reset() > sys.settrace(self.trace_dispatch) > res = None > try: > try: > res = func(*args) > except BdbQuit: > pass > finally: > self.quitting = 1 > sys.settrace(None) > return res > As can be seen, the exception BdbQuit indicating that the "quit" command had > been run is caught and ignored, with the result that None is then returned as > if from the handler itself. This causes the upstream exception to be raised > that the result is not an integer. > One possibility is run replace pdb.runcall() invocation with: > #result = pdb.runcall(object, req) > debugger = pdb.Pdb() > debugger.reset() > sys.settrace(debugger.trace_dispatch) > try: > return object(req) > finally: > debugger.quitting = 1 > sys.settrace(None) > If this is done, the BdbQuit exception ignored and is propogated up. The > error message then at least can be linked better as being related to the > debugger. > Mod_python error: "PythonHandler mptest" > Traceback (most recent call last): > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py", > line 303, in HandlerDispatch > return object(req) > File "/Users/grahamd/Sites/importer/mptest.py", line 5, in handler > req.content_type = 'text/plain' > File "/Users/grahamd/Sites/importer/mptest.py", line 5, in handler > req.content_type = 'text/plain' >File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/bdb.py", > line 48, in trace_dispatch > return self.dispatch_line(frame) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/bdb.py", > line 61, in dispatch_line > if self.quitting: raise BdbQuit > BdbQuit > Alternatively a special purpose error message could be generated to indicate > that the debugging of the handler for that request was explicitly quit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-84) req.sendfile(filename) sends an incorrect number of bytes when filename is a symlink
[ https://issues.apache.org/jira/browse/MODPYTHON-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-84. - > req.sendfile(filename) sends an incorrect number of bytes when filename is a > symlink > > > Key: MODPYTHON-84 > URL: https://issues.apache.org/jira/browse/MODPYTHON-84 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.1.3, 3.1.4, 3.2.7 >Reporter: Jim Gallacher > Assigned To: Graham Dumpleton > Fix For: 3.3, 3.2.10 > > > 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-78) No support for Apache 2.2 yet
[ https://issues.apache.org/jira/browse/MODPYTHON-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-78. - > No support for Apache 2.2 yet > - > > Key: MODPYTHON-78 > URL: https://issues.apache.org/jira/browse/MODPYTHON-78 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.7 >Reporter: Nicolas Lehuen > Assigned To: Jim Gallacher > Fix For: 3.3, 3.2.10 > > 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[
https://issues.apache.org/jira/browse/MODPYTHON-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-77.
-
> The multiple interpreter concept of mod_python is broken for Python extension
> modules since Python 2.3
> --
>
> Key: MODPYTHON-77
> URL: https://issues.apache.org/jira/browse/MODPYTHON-77
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.4
> Environment: Python >= 2.3
>Reporter: Boyan Boyadjiev
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-54) Add a way to import a published page into another published page
[
https://issues.apache.org/jira/browse/MODPYTHON-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-54.
-
> Add a way to import a published page into another published page
>
>
> Key: MODPYTHON-54
> URL: https://issues.apache.org/jira/browse/MODPYTHON-54
> Project: mod_python
> Issue Type: Improvement
> Components: importer
>Affects Versions: 3.2.7
>Reporter: Nicolas Lehuen
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> Before mod_python 3.2, standard Python modules and published modules could be
> imported the same way, using apache.import_module. This had a number of
> disadvantages, leading to MODPYTHON-8, MODPYTHON-9, MODPYTHON-10,
> MODPYTHON-11 and MODPYTHON-12.
> All these bugs were fixed by separating the published modules from the
> standard Python module. apache.import_module can still be used to import
> standard modules, but published modules are now fully managed by
> mod_python.publisher, and are not inserted into sys.modules.
> The problem is that there is a use case of importing a published module from
> another published module :
> /index.py
> def index(req):
> return "Hello, world !"
> def utility_function(foobar):
> return foobar+1
> /other.py
> import os
> directory = os.path.split(__file__)[0]
> other_index = apache.import_module("index",path=[directory])
> def index(req):
> return "%s %i"%(other_index.index(req),other_index.utility_function(2004))
> This was alread a bit of a hack in 3.1.4, but in 3.2 it does not really work
> the expected way since the imported module (other_index in the example) is
> not the same module as the one the publisher would use to publish /index.py.
> This could be troublesome if the developer wanted to share some data between
> the modules, e.g. a cache or a connection pool, but not if he only wanted to
> share some code.
> Therefore, we need to provide a clean API in mod_python.publisher to allow
> developers to reference another published module.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-63) Handle wildcard in Directory to sys.path transfer
[
https://issues.apache.org/jira/browse/MODPYTHON-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-63.
-
> Handle wildcard in Directory to sys.path transfer
> -
>
> Key: MODPYTHON-63
> URL: https://issues.apache.org/jira/browse/MODPYTHON-63
> Project: mod_python
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.1.3
> Environment: gentoo Linux 2.4.20-gentoo-r8 apache-2.0.54-r8
> mod_python-3.1.3-r1
>Reporter: Kevin Quick
> Assigned To: Graham Dumpleton
>Priority: Minor
> Fix For: 3.3
>
>
> Below is a patch that does two things:
> 1) On module import failures, logfile contains additional information showing
>system paths as well as module name.
> 2) Support of Python*Handler found in a wildcard-based directory. For
> example,
>
>
> AddHandler mod_python .py
> PythonHandler helloworld
> PythonDebug on
>
>
> which mirrors a corresponding perl setting and would allow the user to
> place a mod_python handler in their $HOME/public_html/python directory.
> In the current code, the wildcard is not translated, the sys.path update
> will be invalid, and the user's module will not be accessible. The attached
> patch provides a fix for this.
> N.B. There are obvious security issues in using this type of configuration,
> but this is very useful for dev environments, and security would implemented
> via explicit alternatives anyhow.
> Index: apache.py
> ===
> RCS file: /home/cvspublic/httpd-python/lib/python/mod_python/apache.py,v
> retrieving revision 1.83
> diff -r1.83 apache.py
> 33a34,40
> > def add_handler_path(hpath):
> > import glob
> > if hpath:
> > for D in glob.glob(hpath):
> > if os.path.isdir(D) and D not in sys.path:
> > sys.path.insert(0, D)
> >
> 170,171c177
> < if filter.dir and (filter.dir not in sys.path):
> < sys.path[:0] = [filter.dir]
> ---
> > add_handler_path(filter.dir)
> 280,282c286
> < dir = hlist.directory
> < if dir and (dir not in sys.path):
> < sys.path[:0] = [dir]
> ---
> > add_handler_path(hlist.directory)
> 454c458,462
> < f, p, d = imp.find_module(parts[i], path)
> ---
> > try:
> > f, p, d = imp.find_module(parts[i], path)
> > except:
> > _apache.log_error("mod_python: import error for module %s
> > with path: %s and sys.path: %s"%(parts[i],path,sys.path))
> > raise
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-47) Digest Authorization header causes bad request error.
[ https://issues.apache.org/jira/browse/MODPYTHON-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-47. - > Digest Authorization header causes bad request error. > - > > Key: MODPYTHON-47 > URL: https://issues.apache.org/jira/browse/MODPYTHON-47 > Project: mod_python > Issue Type: Bug > Components: publisher >Affects Versions: 3.1.4 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton >Priority: Minor > Fix For: 3.3 > > Attachments: MP47_20060307_grahamd_1.diff, > MP47_20060309_grahamd_2.diff > > > If Apache is used to perform authentication, the Authorization header still > gets > passed through to mod_python.publisher. Unfortunately, mod_python.publisher > authentication code in process_auth() will attempt to decode the contents of > the > Authorization header even if there are no __auth__ or __access__ hooks defined > for authentication and access control within the published code itself. > The consequence of this is that if Digest authentication is used for AuthType > at level of Apache authentication, the process_auth() code will raise a bad > request > error as it assumes Authorization header is always in format for Basic > authentication > type and when it can't decode it, it raises an error. > What should happen is that any decoding of Authorization should only be done > if there is a __auth__ or __access__ hook that actually requires it. That > way, if some > one uses Digest authentication at Apache configuration file level, provided > that no > __auth__ or __access__ hooks are provided, there wouldn't be a problem. > See: > http://www.modpython.org/pipermail/mod_python/2005-April/017911.html > http://www.modpython.org/pipermail/mod_python/2005-April/017912.html > for additional information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-43) mod_python.publisher auth functions access to globals
[
https://issues.apache.org/jira/browse/MODPYTHON-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-43.
-
> mod_python.publisher auth functions access to globals
> -
>
> Key: MODPYTHON-43
> URL: https://issues.apache.org/jira/browse/MODPYTHON-43
> Project: mod_python
> Issue Type: Improvement
> Components: publisher
>Affects Versions: 3.1.4
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
>Priority: Minor
> Fix For: 3.3
>
> Attachments: grahamd_20060224_MP43_1.diff
>
>
> In the mod_python.publisher code, the code for performing basic authentication
> has in a few spots code of the form:
> if "__auth__" in func_code.co_names:
> i = list(func_code.co_names).index("__auth__")
> __auth__ = func_code.co_consts[i+1]
> if hasattr(__auth__, "co_name"):
> __auth__ = new.function(__auth__, globals())
> found_auth = 1
> What this does is that if the target of the request is a function and that
> function
> contains a nested function, which in this case is called "__auth__", then that
> nested function is turned into a callable object and is subsequently called to
> determine if the user is able to perform the request.
> In making the nested function callable, it uses "globals()". By using this
> though
> it is using the globals from the mod_python.publisher module and not the
> module which the nested function is contained within. This means that the
> following code will actually fail.
> import xxx
> def function(req):
> def __auth__(req,username,password):
> return xxx.auth(req,username,password)
> This is because the module "xxx" imported at global scope within the module
> isn't
> available to the nested function when it is called as it is seeing the
> globals of
> mod_python.publisher instead. To get around the problem, the import has to be
> local to the nested function.
> def function(req):
> def __auth__(req,username,password):
> import xxx
> return xxx.auth(req,username,password)
> Since in this case the auth function being called is a nested function, we
> know that
> we can actually grab the globals for the correct module by getting
> "func_globals"
> from the enclosing function.
> if "__auth__" in func_code.co_names:
> i = list(func_code.co_names).index("__auth__")
> __auth__ = func_code.co_consts[i+1]
> if hasattr(__auth__, "co_name"):
> __auth__ = new.function(__auth__, object.func_globals)
> found_auth = 1
> Ie., instead of "globals()", use "object.func_globals" where "object is the
> enclosing
> function object.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-27) mod_python.publisher authentication
[ https://issues.apache.org/jira/browse/MODPYTHON-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-27. - > mod_python.publisher authentication > --- > > Key: MODPYTHON-27 > URL: https://issues.apache.org/jira/browse/MODPYTHON-27 > Project: mod_python > Issue Type: New Feature > Components: publisher >Affects Versions: 3.1.4 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton >Priority: Minor > Fix For: 3.3 > > > The documentation for mod_python.publisher gives that more specific > authentication > check can be performed on a function by using code: > def sensitive(req): >def __auth__(req, user, password): > if user == 'spam' and password == 'eggs': > # let them in > return 1 > else: > # no access > return 0 ># something involving sensitive information >return 'sensitive information` > Ie., authentication function can be nested inside the actual function. > This only works for functions and not methods of a class. Thus, code could be > enhanced > to allow it to work for MethodType as well as FunctionType. Method that needs > to be > changed is process_auth() and it simply needs to track through im_func to get > to the > func_code member. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-38) Passing req.form into psp.PSP().
[ https://issues.apache.org/jira/browse/MODPYTHON-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-38. - > Passing req.form into psp.PSP(). > > > Key: MODPYTHON-38 > URL: https://issues.apache.org/jira/browse/MODPYTHON-38 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.1.4 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton >Priority: Minor > Fix For: 3.3 > > > When calling psp.PSP() explicitly to render PSP pages, it will internally > setup > req.form if it determines that the form is accessed by the PSP page. > Problem is that if you are wanting to trigger psp.PSP() from a publisher > function > any form parameters have already been processed and req.form created. For a > POST request this is problematic as in doing this it will have consumed all > the > content of the request. > This means that when the form is processed a second time by psp.PSP(), it will > find no request content. Thus, the PSP page will only be able to make use of > GET form parameters and not POST form parameters. > It would be an improvement if psp.PSP() allowed a instance of > util.FieldStorage > which has previously been created to be passed in through the "form" parameter > of the constructor. Ie., > template = psp.PSP(req,filename=path,vars=settings,form=req.form) > template.run() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-8) Improve apache.load_module with a two-level locking scheme
[ https://issues.apache.org/jira/browse/MODPYTHON-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-8. > Improve apache.load_module with a two-level locking scheme > -- > > Key: MODPYTHON-8 > URL: https://issues.apache.org/jira/browse/MODPYTHON-8 > Project: mod_python > Issue Type: Improvement > Components: importer >Affects Versions: 3.1.3 >Reporter: Nicolas Lehuen > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > We should rewrite apache.load_python with a two level locking scheme, in > order to reduce thread contention when using the threading MPM. > I've already implemented something similar for a custom-made publisher system > (comparable to Graham's Vampire) ; I've used a thread-safe caching system > that I've donated to the Python Cookbook : > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302997 > Maybe this should be experimented in a separate branch, and merged back once > we're sure that everything works perfectly ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-214) Look more into Win32 compiler warnings.
Look more into Win32 compiler warnings. --- Key: MODPYTHON-214 URL: https://issues.apache.org/jira/browse/MODPYTHON-214 Project: mod_python Issue Type: Task Reporter: Graham Dumpleton Priority: Minor Compilation on Win32 using VisualStudio project file throws up a lot of warnings still with 3.3. This was highlighted by Jeff Robins. http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200611.mbox/[EMAIL PROTECTED] The errors from the post are: -- Build started: Project: mod_python, Configuration: Release Win32 -- Compiling... finfoobject.c c:\Python25\include\pyconfig.h(309) : warning C4005: 'PLATFORM' : macro redefinition c:\Program Files\Apache Software Foundation\Apache2.2\include\os.h(41) : see previous definition of 'PLATFORM' finfoobject.c(129) : warning C4047: 'function' : 'long' differs in levels of indirection from 'apr_uid_t' finfoobject.c(137) : warning C4047: 'function' : 'long' differs in levels of indirection from 'apr_gid_t' finfoobject.c(145) : warning C4244: 'function' : conversion from 'apr_ino_t' to 'long', possible loss of data finfoobject.c(173) : warning C4244: 'function' : conversion from 'apr_off_t' to 'long', possible loss of data finfoobject.c(183) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data finfoobject.c(191) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data finfoobject.c(199) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data util.c util.c(122) : warning C4244: 'function' : conversion from 'apr_ino_t' to 'long', possible loss of data util.c(140) : warning C4047: 'function' : 'long' differs in levels of indirection from 'apr_uid_t' util.c(146) : warning C4047: 'function' : 'long' differs in levels of indirection from 'apr_gid_t' util.c(152) : warning C4244: 'function' : conversion from 'apr_off_t' to 'long', possible loss of data util.c(158) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data util.c(164) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data util.c(170) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data tableobject.c serverobject.c requestobject.c requestobject.c(886) : warning C4244: '=' : conversion from 'apr_off_t' to 'long', possible loss of data requestobject.c(986) : warning C4244: '=' : conversion from 'apr_off_t' to 'long', possible loss of data requestobject.c(1434) : warning C4244: '=' : conversion from 'apr_off_t' to 'apr_size_t', possible loss of data requestobject.c(1609) : warning C4244: 'initializing' : conversion from 'apr_off_t' to 'long', possible loss of data mod_python.c mod_python.c(429) : warning C4101: 'mutex_dir' : unreferenced local variable mod_python.c(1985) : warning C4244: 'function' : conversion from 'apr_off_t' to 'apr_size_t', possible loss of data mod_python.c(2028) : warning C4101: 'tmp_buck' : unreferenced local variable hlistobject.c hlist.c filterobject.c filterobject.c(234) : warning C4018: '>' : signed/unsigned mismatch filterobject.c(243) : warning C4018: '<' : signed/unsigned mismatch connobject.c connobject.c(155) : warning C4018: '>' : signed/unsigned mismatch _apachemodule.c Compiling resources... Linking... Creating library .\Release/mod_python.lib and object .\Release/mod_python.exp Build log was saved at "file://c:\work\mod_python-3.3.0-dev-20061109\src\Release\BuildLog.htm" mod_python - 0 error(s), 25 warning(s) Compiling with -Wall on UNIX systems when using gcc might help as default options on gcc may not be showing these, that or it comes down to different type definitions on Win32. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MODPYTHON-213) Investigate being able to create sessions as 'secure' or 'httponly'.
Investigate being able to create sessions as 'secure' or 'httponly'. Key: MODPYTHON-213 URL: https://issues.apache.org/jira/browse/MODPYTHON-213 Project: mod_python Issue Type: Task Components: session Reporter: Graham Dumpleton Priority: Minor As per original request: http://www.modpython.org/pipermail/mod_python/2006-December/022803.html and subsequent discussion, investigate whether sessions should be able to be created such that the underlying cookie is using either the 'httponly' or 'secure' cookie attributes. Note that the thread in the mailing list archive doesn't join together properly so you need to look for the similar subject lines in the thread index. At the end of the discussion it wasn't completely clear how things would behave if these attributes were used and thus what the outcome would be so it wasn't pursued further. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MODPYTHON-212) req.read() with no arguments doesn't return all data where input filter inserts extra data in input stream.
req.read() with no arguments doesn't return all data where input filter inserts extra data in input stream. --- Key: MODPYTHON-212 URL: https://issues.apache.org/jira/browse/MODPYTHON-212 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.10, 3.3 Reporter: Graham Dumpleton The req.read() function when supplied with no arguments is supposed to return all available data from the request body input stream. To do this it uses req.remaining as the amount of data still to be read and will only read up to that amount of data. The problem with this is that req.remaining is originally set to be the value of the Content-Length header of the request. This however may not actually be how much data there is to read as input filters may actually remove or add data to the input stream. This will not cause a problem when an input filter removes data as the amount it thinks there is to read will still be more than what is actually available after the input filter has removed data. In the case of an input filter that inserts additional data, the amount of data to be read will actually exceed the value of req.remaining and as a consequence req.read() will not return all the available data. Even subsequent calls to req.read() with no arguments will not return all the data as req.remaining by then is zero and it will think it has read all the available data. The only way to get all the data is to make successive calls to req.read() but supply some size as argument. Calls should be made to req.read() with the argument until req.read() returns an empty string. Only when it returns an empty string are you sure all data has been returned. This problem will also affect req.readline() as it uses req.remaining in a similar way. The req.readlines() function is also possibly indirectly affected as it calls req.readline() to read individual lines and so it may not be able to access any additional lines beyond the original content length specified in the request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MODPYTHON-211) Potential memory leak in req.readlines().
Potential memory leak in req.readlines().
-
Key: MODPYTHON-211
URL: https://issues.apache.org/jira/browse/MODPYTHON-211
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10, 3.3
Reporter: Graham Dumpleton
This code in req.readlines() looks a bit fishy to me and possibly leaks memory.
The code in question is:
rlargs = PyTuple_New(0);
if (result == NULL)
return PyErr_NoMemory();
line = req_readline(self, rlargs);
while (line && ((linesize=PyString_Size(line))>0)) {
PyList_Append(result, line);
size += linesize;
if ((sizehint != -1) && (size >= sizehint))
break;
Py_DECREF(line);
line = req_readline(self, args);
}
Py_XDECREF(line);
The thing that looks wrong is 'rlargs'. This is created, used in a sub call to
req_readline() but then never destroyed. Thus, possibly a memory leak.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MODPYTHON-210) FieldStorage wrongly assumes boundary is last attribute in Content-Type headers value.
FieldStorage wrongly assumes boundary is last attribute in Content-Type headers
value.
--
Key: MODPYTHON-210
URL: https://issues.apache.org/jira/browse/MODPYTHON-210
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10, 3.3
Reporter: Graham Dumpleton
Mozilla can generate multipart content that looks like:
Content-Length: 522
Content-Type: multipart/related;
boundary=---13592280651221337293469391600;
type="application/xml"; start="<[EMAIL PROTECTED] >"
Cookie: lang=1
This highlights an issue with util.FieldStorage in that it assumes that the
boundary attribute of the Content-Type header will always be the last thing in
the value. Ie., the code in FieldStorage is:
# figure out boundary
try:
i = ctype.lower().rindex("boundary=")
boundary = ctype[i+9:]
if len(boundary) >= 2 and boundary[0] == boundary[-1] == '"':
boundary = boundary[1:-1]
boundary = re.compile("--" + re.escape(boundary) + "(--)?\r?\n")
The FieldStorage code should correctly split out all attributes from the line
and then deal with list the boundary attribute by itself and not make
assumptions about the order of attributes on the line. The code is also
questionable depending on whether it is guaranteed by Apache that trailing
space is striped from the value of headers. If there is trailing white space it
will interfere with the check for whether the boundary is surrounded by quotes.
Finally, does the specification for HTTP headers always entail the use of a
double quote as this is the only thing that is checked for?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-143) Implement and integrate a new module importer.
[ http://issues.apache.org/jira/browse/MODPYTHON-143?page=all ] Graham Dumpleton resolved MODPYTHON-143. Resolution: Fixed Basic documentation added for apache.import_module() and all outstanding code changes complete, so finally time to mark this as resolved. Time to roll out 3.3 and thence onward to 3.4/4.0 and beyond. ;-) > Implement and integrate a new module importer. > -- > > Key: MODPYTHON-143 > URL: http://issues.apache.org/jira/browse/MODPYTHON-143 > Project: mod_python > Issue Type: Task > Components: importer >Affects Versions: 3.2.8 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > This is an overall task to cover the issue of rectifying the various module > importer issues by replacing it with a new implementation. A description of > the various problems can be found in: > http://www.dscpl.com.au/articles/modpython-003.html > Separate issues had already been created for some of the specific problems. > These issues will now be linked to this problem and thus marked as being > dependent on this issue. > In other words, replacing the module importer will solve a number of number > issues. Rather than try and keep up to date all the separate issues, all > information about the replacement will be put against this issue instead. > Note that there are also some issues which are not directly related to the > module importer but which will be made dependent on this issue because it is > easier to fix the issue as part of the rewrite of the module importer and top > level handler dispatch mechanism than it is to address it as a distinct item. > In respect of what impacts the new module importer implementation may have > and how it is used may change, this will be documented in the following > document for the time being: > http://www.dscpl.com.au/articles/modpython-007.html > Note that this document is a work in progress. It is dense reading and > assumes you know a bit about the current module importer and its problems. > Any significant issues raised by this document can be added here as a > comment, or if a general dicussion of a topic is needed, raise the issue on > the mod_python developers mailing list. > A possible new implementation for the module importer is basically ready for > testing and experimentation. The intent is to push it into the mod_python > source tree, but for its use to be optional. > If wanting to enable it for a specific Python interpreter, the PythonImport > directive would be used: > PythonImport mod_python.future.importer mytestinterpreter > If wanting to enable it for all Python interpreters, a PythonOption directive > would be used at global scope within the Apache configuration. Ie., outside > of all Location, Directory or Files container directives. The exact option > name to be used hasn't yet been decided. > More details and announcements at the appropriate time. -- 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 ] Graham Dumpleton reopened MODPYTHON-93: --- After further experimentation, following the Trac model of having __setitem__() be an alias for add_field() is a pain in the neck. As reminder, the Trac way of doing things mean't that assigning using subscript operator resulted in additional field values being added rather than existing ones being replaced as the subscript operator works in every other dictionary like data structure. Having it work this way, it is too easy to forget it is different and your code doesn't work as expected. For newbies this could cause a lot of grief. Thus, how Trac did things should be ignored and need to make __setitem__() replace all existing values for field like a normal dictionary. If someone wants to add additional values, they should use add_field() instead. Doing this will not cause any problems for Trac compatibility as Trac overrides __setitem__() in a derived class anyway. > Improve util.FieldStorage efficiency > > > Key: MODPYTHON-93 > URL: http://issues.apache.org/jira/browse/MODPYTHON-93 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.2.7 >Reporter: Jim Gallacher > Assigned To: Graham Dumpleton >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] Work started: (MODPYTHON-93) Improve util.FieldStorage efficiency
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=all ] Work on MODPYTHON-93 started by Graham Dumpleton. > Improve util.FieldStorage efficiency > > > Key: MODPYTHON-93 > URL: http://issues.apache.org/jira/browse/MODPYTHON-93 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.2.7 >Reporter: Jim Gallacher > Assigned To: Graham Dumpleton >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-208) Automatic construction of handler class.
Automatic construction of handler class. Key: MODPYTHON-208 URL: http://issues.apache.org/jira/browse/MODPYTHON-208 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.2.10, 3.3 Reporter: Graham Dumpleton When defining a mod_python handler, it is possible to supply a dotted path for the actual handler function to be used. Ie: PythonHandler module::instance.function when determing the handler to execute, it will use the dotted path to traverse any object hierarchy. Thus the above will execute "function()" of the object instance called "instance" in the module called "module". If instead one provides: PythonHandler module::class.function where 'class' is the name of a class type, then referencing 'function' within that type will result in an instance of the class automatically being created just for the current request, with "function()' then being called on that transient instance of the class. For an instance of the class to be created in this way, one must access a member function of the class type. If an instance of the class is callable in its own right, ie., has a __call__() method, it is not however possible to say: PythonHandler module::class To get that to work, you instead have to use: PythonHandler module::class.__call__ First change should be that if a class is callable through having a __call__() method, then it should not be necessary to reference the __call__() method explicitly, instead, referencing the class type itself should be enough. Ie., using PythonHandler module::class should work. Note that the code will have to be smart enough to handle both new and old style classes. The next issue with this automatic initialisation of a class type is that although the __call__() method needs to accept the 'req' argument, the constructor has to as well if it is being created automatically. The code should allow for the case where the class doesn't want to have to deal with the 'req' object as an argument to the constructor. Ie., it should be optional for the constructor, although always still required for the actual function of the class instance being called. -- 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-209) PythonInitHandler does not work in .htaccess file.
PythonInitHandler does not work in .htaccess file.
--
Key: MODPYTHON-209
URL: http://issues.apache.org/jira/browse/MODPYTHON-209
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10, 3.1.4, 3.3
Reporter: Graham Dumpleton
The documentation says this about the PythonInitHandler:
This handler is the first handler called in the request processing phases
that is allowed
both inside and outside .htaccess and directory.
This handler is actually an alias to two different handlers. When specified
in the main config
file outside any directory tags, it is an alias to PostReadRequestHandler.
When specified
inside directory (where PostReadRequestHandler is not allowed), it aliases to
PythonHeaderParserHandler.
I believe the idea is that instead of having to know whether one should use
PythonPostReadRequestHandler or PythonHeaderParserHandler dependent on whether
you are setting up configuration in either main Apache configuration or
.htaccess file, you just use the PythonInitHandler directive instead in either
the main Apache configuration or the .htaccess file and it will called as
appropriate for either phase automatically based on where it was used.
Problem is that it cannot work in the .htaccess file.
This is because the code for PythonPostReadRequestHandler says:
static int PythonPostReadRequestHandler(request_rec *req) {
int rc;
/* run PythonInitHandler */
rc = python_handler(req, "PythonInitHandler");
apr_table_set(req->notes, "python_init_ran", "1");
if ((rc != OK) && (rc != DECLINED))
return rc;
return python_handler(req, "PythonPostReadRequestHandler");
}
and that for PythonHeaderParserHandler says:
static int PythonHeaderParserHandler(request_rec *req) {
int rc;
/* run PythonInitHandler, if not already */
if (! apr_table_get(req->notes, "python_init_ran")) {
rc = python_handler(req, "PythonInitHandler");
if ((rc != OK) && (rc != DECLINED))
return rc;
}
return python_handler(req, "PythonHeaderParserHandler");
}
The issue is that the table note called 'python_init_ran' is always set in the
first function regardless of whether there was actually a registered
PythonInitHandler that got called as part of the PythonPostReadRequestHandler
phase. Thus, there will never be an opportunity for a PythonInitHandler
registered in a .htaccess file to get called.
The whole idea of the PythonInitHandler is possibly a bit suspect and since the
idea was copied from mod_perl, a look should be made to see what mod_perl 2.0
does and whether they still have it.
One thing that is a bit confusing is why one would want a single alias for
these two different phases, especially since they aren't even adjacent within
the processing sequence. Specifically the Apache phases include:
"postreadrequesthandler"
"transhandler"
"maptostoragehandler" # not implemented by mod_python
"headerparserhandler"
Thus, the two phases are quite separate and the PythonTransHandler comes
between them. Thus, why have them use the same name
--
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-129) HandlerDispatch doesn't treat OK/DECLINED result properly for all phases.
[ http://issues.apache.org/jira/browse/MODPYTHON-129?page=all ] Graham Dumpleton reopened MODPYTHON-129: After further experimentation while going over changes in mod_python 3.3 to ensure that all looks okay, the idea of keeping the content handler phase the same as what it was previously is actually quite limiting and one would loose some nice abilities just to ensure compatibility with just a few, if any at all, existing applications given that there is not really any evidence that anyone uses stacked content handlers. It would be much better to set it now to what is the best way that it can be done. The behaviour as it stands for stacked handlers in the content handler phase is that each handler will in turn be executed while ever they return apache.OK. Thus, if a HTTP error is returned, or if apache.DONE or apache.DECLINED is returned, further processing of stacked handlers is terminated. What is a pain in this is that returning apache.DECLINED causes subsequent stacked handlers not to be run with value of apache.DECLINED. This is contrary to how handlers work in every other phase of Apache processing. The consequence of returning apache.DECLINED is that it causes Apache to immediately fallback to executing the default-handler and thus attempt to serve up a stack file if one exists to satisfy the request. It does not provide any opportunity to attempt to run other mod_python based content handlers. It is much more useful to have returning apache.DECLINED simply cause execution to move onto the next stacked handler, thus preserving its original intent at this level that the handler didn't wish to service the request. This allows a series of content handlers to be attempted with appropriate one doing what it needs to and then returning apache.DONE to indicate that it has completed the request thus stopping subsequent stacked handlers to be run. At the moment one can't do this properly without using hacks which sit on top of mod_python rather than using mod_python itself. Note that although returning apache.OK also results in the next stacked handler then being executed much like apache.DECLINED would, the difference comes where the handler is the last one as the return status of the last one becomes the overall return value of the content phase. Thus, if one has stacked handlers and all return apache.DECLINED indicating that none want to service the request, one still gets the logical result that control then falls back to the default-handler. If one looks at the most probable way that stacked handlers might have been used in existing code, for example: PythonHandler header body footer Every handler would have simply returned apache.OK. As the last handler is returning apache.OK, one still gets the same result anyway and thus there is practically no risk that existing code would be stuffed up anyway. Same deal when there is only a single content handler, still works like it does now and as expected. FWIW, a content handler should probably always return apache.DONE rather than apache.OK except for where stacked handlers are using to complete the request in multiple parts like above. Finally, as the new way of interpreteing return status codes from handlers is only implemented when the new module importer is used, if someone does have code that somehow relies on the old behaviour, they can simply enable the old importer and there code will keep working until they can change how they do things to what is the more logical way. Thus, a migration path of sorts is available. Thus, my intention it to make change as described. > HandlerDispatch doesn't treat OK/DECLINED result properly for all phases. > - > > Key: MODPYTHON-129 > URL: http://issues.apache.org/jira/browse/MODPYTHON-129 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.7 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > Todays daily bug report, or is it? ;-) > The Python*Handler documentation says: > """Multiple handlers can be specified on a single line, in which case they > will be called sequentially, from left to right. Same handler directives can > be specified multiple times as well, with the same result - all handlers > listed will be executed sequentially, from first to last. If any handler in > the sequence returns a value other than apache.OK, then execution of all > subsequent handlers is aborted.""" > That is, no matter which phase is being processed, mod_python will stop > processing them if a value other than OK is returned. > Problem is that this isn't how Apache itself treats the result from handlers. > Apache actually implements two different ways for dealing with the result >
[jira] Work started: (MODPYTHON-129) HandlerDispatch doesn't treat OK/DECLINED result properly for all phases.
[ http://issues.apache.org/jira/browse/MODPYTHON-129?page=all ] Work on MODPYTHON-129 started by Graham Dumpleton. > HandlerDispatch doesn't treat OK/DECLINED result properly for all phases. > - > > Key: MODPYTHON-129 > URL: http://issues.apache.org/jira/browse/MODPYTHON-129 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.7 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > Todays daily bug report, or is it? ;-) > The Python*Handler documentation says: > """Multiple handlers can be specified on a single line, in which case they > will be called sequentially, from left to right. Same handler directives can > be specified multiple times as well, with the same result - all handlers > listed will be executed sequentially, from first to last. If any handler in > the sequence returns a value other than apache.OK, then execution of all > subsequent handlers is aborted.""" > That is, no matter which phase is being processed, mod_python will stop > processing them if a value other than OK is returned. > Problem is that this isn't how Apache itself treats the result from handlers. > Apache actually implements two different ways for dealing with the result > from the handlers. Which is used depends on which processing phase is > occuring. This is all specified by the Apache magic macro code: > AP_IMPLEMENT_HOOK_RUN_FIRST(int,translate_name, > (request_rec *r), (r), DECLINED) > AP_IMPLEMENT_HOOK_RUN_FIRST(int,map_to_storage, > (request_rec *r), (r), DECLINED) > AP_IMPLEMENT_HOOK_RUN_FIRST(int,check_user_id, > (request_rec *r), (r), DECLINED) > AP_IMPLEMENT_HOOK_RUN_FIRST(int,auth_checker, > (request_rec *r), (r), DECLINED) > AP_IMPLEMENT_HOOK_RUN_ALL(int,access_checker, > (request_rec *r), (r), OK, DECLINED) > AP_IMPLEMENT_HOOK_RUN_FIRST(int,type_checker, > (request_rec *r), (r), DECLINED) > AP_IMPLEMENT_HOOK_RUN_ALL(int,fixups, > (request_rec *r), (r), OK, DECLINED) > What this gobblegook expands to are loops which will stop processing handlers > based on the result. > For the AP_IMPLEMENT_HOOK_RUN_ALL macro, all handlers in the phase will be > run unless one returns something other than OK or DECLINED. Returning OK > means that it did something and it worked okay. Returing DECLINED means that > it didn't do anything at all. In both these cases, it still goes onto the > next handler in that phase. After that it will go onto the next phase. > Returning an error will cause appropriate error response to go back to client > with any other handlers in the phase, as well as later phases being skipped. > Returning DONE is much like returning an error but Apache interprets it as > meaning a complete response was constructed and that it doesn't have to > generate any response. > For the AP_IMPLEMENT_HOOK_RUN_FIRST macro, all handlers will be run only if > they all return DECLINED. In other words, if a handler returns OK it will > skip the following handlers in that phase and then move onto the next phase. > Returning an error or DONE is like above. > In the case of mod_python, what it does doesn't fit into either. It is closer > to behaving like the AP_IMPLEMENT_HOOK_RUN_ALL macro except that it stops > processing further handlers in the phase if DECLINED is returned. > As to what problems this causes, imagine you had registered multiple > authentication handlers which supported different authentication mechanisms. > This is the case where AP_IMPLEMENT_HOOK_RUN_FIRST macro is used. The idea > is that each authentication handler would check the value associated with the > AuthType directive to determine if it should do anything. If it was not the > AuthType it implements, if it were a C based handler module, it would > returned DECLINED to indicate it hadn't done anything and that the next > handler should instead be tried. Each handler would thus be called until one > handler says that is for me, says the user is valid and returns OK or returns > an error rejecting it. > If you wanted to write these multiple authentication handlers in Python you > can't do it. This is because the way mod_python works, if you return DECLINED > it would actually skip the remainder of the mod_python declared handlers > whereas you still want them to be executed. Apache would still execute any > other C based handlers in the phase though. The only way to get mod_python to > execute later mod_python handlers in the phase is to return OK, but if you do > that and it happens to be the last handler in the mod_python list of > handlers, it will return OK to Apache and Apach
[jira] Created: (MODPYTHON-205) Python version mismatch check and patch level revisions.
Python version mismatch check and patch level revisions. Key: MODPYTHON-205 URL: http://issues.apache.org/jira/browse/MODPYTHON-205 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.10, 3.3 Reporter: Graham Dumpleton Priority: Minor When mod_python starts up, it performs a check to confirm whether the version of Python it finds at runtime is the same version as was used to compile mod_python originally. It does this by comparing the value of PY_VERSION defined when mod_python is compiled against the runtime derived version from Py_GetVersion(). Because this is a complete version string, it incorporates the patch level revision as well as the major and minor versions. This means mod_python will issue a warning if Python has been updated, but only by a patch revision. Technically, the ABI for patch level revisions of Python should be compatible and a warning about a version mismatch should be needed in this situation. Thus, the check should perhaps be changed to only look at major/minor version differences and not patch level revisions. As an example of this issue, below is bug report from debian bugs list. Package: libapache2-mod-python Version: 3.2.10-2 Severity: critical Justification: breaks unrelated software [Tue Nov 14 18:28:37 2006] [error] python_init: Python version mismatch, expected '2.4.4c1', found '2.4.4'. [Tue Nov 14 18:28:37 2006] [error] python_init: Python executable found '/usr/bin/python'. [Tue Nov 14 18:28:37 2006] [error] python_init: Python path being used '/usr/lib/python24.zip:/usr/lib/python2.4/:/usr/lib/python2.4/plat-linux2:/ usr/lib/python2.4/lib-t k:/usr/lib/python2.4/lib-dynload'. [Tue Nov 14 18:28:37 2006] [notice] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads. [Tue Nov 14 18:28:37 2006] [notice] mod_python: using mutex_directory /tmp Need recompile the mod-python :D -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-686 Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Versions of packages libapache2-mod-python depends on: ii apache2 2.2.3-3.1 Next generation, scalable, extenda ii apache2-mpm-prefork [apache2 2.2.3-3.1 Traditional model for Apache HTTPD ii apache2.2-common 2.2.3-3.1 Next generation, scalable, extenda ii debconf [debconf-2.0]1.5.8 Debian configuration management sy ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii python 2.4.4-1 An interactive high-level object-o ii python-central 0.5.10 register and build utility for Pyt ii python2.42.4.4-1 An interactive high-level object-o libapache2-mod-python recommends no packages. -- debconf information: libapache2-mod-python/enable_module: true -- 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-186) Build process not using correct values from Python config Makefile.
[ http://issues.apache.org/jira/browse/MODPYTHON-186?page=comments#action_12449856 ] Graham Dumpleton commented on MODPYTHON-186: Someone has successfuly built mod_python on Mac OS X using: gcc version 4.0.1 (Apple Computer, Inc. build 5367) Thus, may have been a problem with the particular persons setup, or some issue has been fixed in newer version of XCode. > Build process not using correct values from Python config Makefile. > --- > > Key: MODPYTHON-186 > URL: http://issues.apache.org/jira/browse/MODPYTHON-186 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.3, 3.2.10 >Reporter: Graham Dumpleton > > As found by Justin Erenkrantz, the build process for mod_python is using > LINKFORSHARED from the Python config Makefile. On Mac OS X though this > results in a expansion of: > LDFLAGS= -Wl,-framework,Python -u __dummy -u _PyMac_Error -framework System > $(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK) -framework > CoreServices -framework Foundation -Wl,-F. -Wl,-F. > where PYTHONFRAMEWORKDIR, VERSION and PYTHONFRAMEWORK aren't defined at the > point of expansion. Thus the compile executes with options: > .../libtool --silent --mode=link ccache gcc -o mod_python.la -rpath > .../httpd-trunk/modules -module -avoid-versionhlistobject.lo hlist.lo > filterobject.lo connobject.lo serverobject.lo util.lo tableobject.lo > requestobject.lo _apachemodule.lo mod_python.lo -Wl,-framework,Python -u > __dummy -u _PyMac_Error -framework System /Versions// -framework CoreServices > -framework Foundation -Wl,-F. -Wl,-F. -lm -framework Python -ldl > Ie., '/Versions//' gets passed as an option. > So far this has been working without a problem, but looks like the version of > gcc which has been supplied with version of XCode distributed around time of > Apple WWDC in August 06 no longer will accept this and produces the error: > powerpc-apple-darwin8-gcc-4.0.1: /Versions//: No such file or directory > Last known version of gcc to accept it is: > gcc version 4.0.1 (Apple Computer, Inc. build 5341) > Version that no longer accepts it is: > gcc version 4.0.1 (Apple Computer, Inc. build 5363) > Suggestion was that LDSHARED should be used instead of LINKFORSHARED. > Apparently Subversion had had to address similar problem so can learn from > what they have done. > Should be fixed for 3.3 and back ported to 3.2.x or we are going to start > getting a lot of complaints. -- 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-204) Implement urlobject to be returned by req.parsed_uri
Implement urlobject to be returned by req.parsed_uri Key: MODPYTHON-204 URL: http://issues.apache.org/jira/browse/MODPYTHON-204 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.3 Reporter: Graham Dumpleton In mod_python 3.3, a finfoobject was introduced and returned when req.finfo was accessed. This provided backward compatibility so that tuple style access still worked, but prefered means of accessing data now is by attribute lookup. In a similar way, a urlobject needs to be introduced so that parts of parsed uri information are accessed by attribute lookup rather than tuple style access. For example: req.parsed_uri.path instead of: req.parsed_uri[apache.URI_PATH] -- 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-203) Constrain what can be accessed when eval'ing module search paths.
Constrain what can be accessed when eval'ing module search paths. - Key: MODPYTHON-203 URL: http://issues.apache.org/jira/browse/MODPYTHON-203 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.2.10, 3.3 Reporter: Graham Dumpleton Priority: Minor When one uses PythonPath it is possible to access sys.path so that the path can be extended rather than replaced. That sys.path is accessible is merely a result of the fact that the eval() performed on the value of PythonPath is done without restricting the globals/locals and so it picks up the environment from the context in which the eval() is performed. As it happens, the module doing this has imported the 'sys' module and therefore it works. The problem is that that module imports other stuff and also holds lots of internal data and functions. All of this data and the functions can also be accessed. For starters, the globals/locals of the eval should possibly be constrained to only allow reference to sys.path and nothing else. Beyond that, we might consider whether access should be provided to other stuff which might be relevant in dynamically constructing a module search path. For example, should stuff like 'apache.main_server' be accessible along with stuff like 'os.path'. This would allow something like: PythonPath "sys.path+[os.path.join(apache.main_server.get_options()['MYAPPROOT'],'modules')]" Or is this just asking for trouble? At the least, should constrain access to just sys.path when evaling PythonPath. In a similar way, also in 3.3 now have mod_python.importer.path. This path should never reference sys.path, yet it is accessible when the eval() is performed. This should be constrained so that sys.path is not accessible at all. There might be other stuff though that we might want to allow access to, although one can already use '~/' prefix in the importer path to reference stuff relative to handler root, so possibly less call for it. -- 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-195) Possible leaking of Win32 event handles when Apache restarted.
[ http://issues.apache.org/jira/browse/MODPYTHON-195?page=all ]
Graham Dumpleton resolved MODPYTHON-195.
Resolution: Fixed
Haven't been able to validate this first hand, but have accepted the following
change in python_init() to stop Win32 parent process performing global mutex
and Python initialisation.
#ifdef WIN32
/* No need to run python_init() in Win32 parent processes as
* the lack of fork on Win32 means we get no benefit as far as
* inheriting a preinitialized Python interpreter. Further,
* upon a restart on Win32 platform the python_init() function
* will be called again in the parent process but without some
* resources allocated by the previous call having being
* released properly, resulting in memory and Win32 resource
* leaks.
*/
if (!getenv("AP_PARENT_PID"))
return OK;
#endif /* WIN32 */
See MODPYTHON-195 thread at:
http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200611.mbox/thread
starting with:
http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200611.mbox/[EMAIL
PROTECTED]
> Possible leaking of Win32 event handles when Apache restarted.
> --
>
> Key: MODPYTHON-195
> URL: http://issues.apache.org/jira/browse/MODPYTHON-195
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.10
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> Jeff Robins in:
>
> http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL
> PROTECTED]
> indicates a belief that when an Apache restart is performed on Windows that
> there are a number of Win32 event handles leaked. His belief is that this
> seems to be linked to mod_python.
--
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] Work started: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ http://issues.apache.org/jira/browse/MODPYTHON-195?page=all ] Work on MODPYTHON-195 started by Graham Dumpleton. > Possible leaking of Win32 event handles when Apache restarted. > -- > > Key: MODPYTHON-195 > URL: http://issues.apache.org/jira/browse/MODPYTHON-195 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.10 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > Jeff Robins in: > > http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL > PROTECTED] > indicates a belief that when an Apache restart is performed on Windows that > there are a number of Win32 event handles leaked. His belief is that this > seems to be linked to mod_python. -- 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-195) Possible leaking of Win32 event handles when Apache restarted.
[ http://issues.apache.org/jira/browse/MODPYTHON-195?page=all ] Graham Dumpleton reassigned MODPYTHON-195: -- Assignee: Graham Dumpleton > Possible leaking of Win32 event handles when Apache restarted. > -- > > Key: MODPYTHON-195 > URL: http://issues.apache.org/jira/browse/MODPYTHON-195 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.10 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > Jeff Robins in: > > http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL > PROTECTED] > indicates a belief that when an Apache restart is performed on Windows that > there are a number of Win32 event handles leaked. His belief is that this > seems to be linked to mod_python. -- 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-202) Allow mechanism used by global mutex locks to be specified.
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] Work started: (MODPYTHON-200) Can't use signed and marshalled cookies together.
[ http://issues.apache.org/jira/browse/MODPYTHON-200?page=all ]
Work on MODPYTHON-200 started by Graham Dumpleton.
> Can't use signed and marshalled cookies together.
> -
>
> Key: MODPYTHON-200
> URL: http://issues.apache.org/jira/browse/MODPYTHON-200
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.10
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> As reported by Clodoaldo Pinto Neto on mailing list:
> http://www.modpython.org/pipermail/mod_python/2006-October/022427.html
> one cannot use signed and marshalled cookies together.
> For example, with publisher code example:
> from mod_python import Cookie
> def makecookies(req):
> c = Cookie.MarshalCookie('marshal', 'value', 'secret')
> d = Cookie.SignedCookie('signed', 'value', 'secret')
> Cookie.add_cookie(req, c)
> Cookie.add_cookie(req, d)
> return 'made\n' + str(req.headers_out)
> def showcookies(req):
> cookies = Cookie.get_cookies(req, Cookie.MarshalCookie, secret='secret')
> s = 'There are %s cookies'% len(cookies)
> for c in cookies.values():
> s += '\n%s %s' % (str(c), type(c))
> return 'read\n' + repr(cookies) + '\n' + s + '\n' + str(req.headers_in)
> if one access makecookies and then showcookies, you get:
> Traceback (most recent call last):
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/importer.py",
> line 1519, in HandlerDispatch
> default=default_handler, arg=req, silent=hlist.silent)
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/importer.py",
> line 1224, in _process_target
> result = _execute_target(config, req, object, arg)
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/importer.py",
> line 1123, in _execute_target
> result = object(arg)
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/publisher.py",
> line 213, in handler
> published = publish_object(req, object)
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/publisher.py",
> line 425, in publish_object
> return publish_object(req,util.apply_fs_data(object, req.form, req=req))
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/util.py",
> line 546, in apply_fs_data
> return object(**args)
> File "/Users/grahamd/public_html/cookies/index.py", line 11, in showcookies
> cookies = Cookie.get_cookies(req, Cookie.MarshalCookie, secret='secret')
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/Cookie.py",
> line 352, in get_cookies
> return Class.parse(cookies, **kw)
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/Cookie.py",
> line 254, in parse
> c.unmarshal(secret)
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/Cookie.py",
> line 282, in unmarshal
> self.value = marshal.loads(base64.decodestring(self.value))
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/base64.py",
> line 44, in decodestring
> return binascii.a2b_base64(s)
> Error: Incorrect padding
> The problem is that Cookie.get_cookies() makes assumption that all cookies
> being sent by browser will be of the same derived type, or are a basic
> cookie. If mixing derived types and they are not compatible as far as
> unpacking goes, the code will fail.
> For starters, there should be a new function called Cookie.get_cookie() where
> you name the cookie and it only tries to decode that one cookie. This new
> method should also be used in the Session class instead of using
> Cookie.get_cookies().
--
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-200) Can't use signed and marshalled cookies together.
Can't use signed and marshalled cookies together.
-
Key: MODPYTHON-200
URL: http://issues.apache.org/jira/browse/MODPYTHON-200
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10
Reporter: Graham Dumpleton
Assigned To: Graham Dumpleton
Fix For: 3.3
As reported by Clodoaldo Pinto Neto on mailing list:
http://www.modpython.org/pipermail/mod_python/2006-October/022427.html
one cannot use signed and marshalled cookies together.
For example, with publisher code example:
from mod_python import Cookie
def makecookies(req):
c = Cookie.MarshalCookie('marshal', 'value', 'secret')
d = Cookie.SignedCookie('signed', 'value', 'secret')
Cookie.add_cookie(req, c)
Cookie.add_cookie(req, d)
return 'made\n' + str(req.headers_out)
def showcookies(req):
cookies = Cookie.get_cookies(req, Cookie.MarshalCookie, secret='secret')
s = 'There are %s cookies'% len(cookies)
for c in cookies.values():
s += '\n%s %s' % (str(c), type(c))
return 'read\n' + repr(cookies) + '\n' + s + '\n' + str(req.headers_in)
if one access makecookies and then showcookies, you get:
Traceback (most recent call last):
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/importer.py",
line 1519, in HandlerDispatch
default=default_handler, arg=req, silent=hlist.silent)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/importer.py",
line 1224, in _process_target
result = _execute_target(config, req, object, arg)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/importer.py",
line 1123, in _execute_target
result = object(arg)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/publisher.py",
line 213, in handler
published = publish_object(req, object)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/publisher.py",
line 425, in publish_object
return publish_object(req,util.apply_fs_data(object, req.form, req=req))
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/util.py",
line 546, in apply_fs_data
return object(**args)
File "/Users/grahamd/public_html/cookies/index.py", line 11, in showcookies
cookies = Cookie.get_cookies(req, Cookie.MarshalCookie, secret='secret')
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/Cookie.py",
line 352, in get_cookies
return Class.parse(cookies, **kw)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/Cookie.py",
line 254, in parse
c.unmarshal(secret)
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/Cookie.py",
line 282, in unmarshal
self.value = marshal.loads(base64.decodestring(self.value))
File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/base64.py",
line 44, in decodestring
return binascii.a2b_base64(s)
Error: Incorrect padding
The problem is that Cookie.get_cookies() makes assumption that all cookies
being sent by browser will be of the same derived type, or are a basic cookie.
If mixing derived types and they are not compatible as far as unpacking goes,
the code will fail.
For starters, there should be a new function called Cookie.get_cookie() where
you name the cookie and it only tries to decode that one cookie. This new
method should also be used in the Session class instead of using
Cookie.get_cookies().
--
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] Deleted: (MODPYTHON-199) Can
[ http://issues.apache.org/jira/browse/MODPYTHON-199?page=all ] Graham Dumpleton deleted MODPYTHON-199: --- > Can > --- > > Key: MODPYTHON-199 > URL: http://issues.apache.org/jira/browse/MODPYTHON-199 > Project: mod_python > Issue Type: Bug >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > -- 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-199) Can
Can --- Key: MODPYTHON-199 URL: http://issues.apache.org/jira/browse/MODPYTHON-199 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 -- 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-195) Possible leaking of Win32 event handles when Apache restarted.
[
http://issues.apache.org/jira/browse/MODPYTHON-195?page=comments#action_12444283
]
Graham Dumpleton commented on MODPYTHON-195:
But python_init() uses:
apr_pool_userdata_get(&data, userdata_key, s->process->pool);
if (!data) {
apr_pool_userdata_set((const void *)1, userdata_key,
apr_pool_cleanup_null, s->process->pool);
return OK;
}
This is apparently a standard trick used to get around fact that
post_config_hook functions are called twice. For example, from
mod_auth_digest.c in Apache source code:
/* initialize_module() will be called twice, and if it's a DSO
* then all static data from the first call will be lost. Only
* set up our static data on the second call. */
apr_pool_userdata_get(&data, userdata_key, s->process->pool);
if (!data) {
apr_pool_userdata_set((const void *)1, userdata_key,
apr_pool_cleanup_null, s->process->pool);
return OK;
}
Thus, although it does get called twice, wouldn't expect it to get down to the
mutex creation as above should stop it.
Jeff, can you do further debugging to track what happens with access to
userdata above on each call and whether it does in fact stop subsequent code
from executing the first time through and post any results against this issue
in JIRA.
> Possible leaking of Win32 event handles when Apache restarted.
> --
>
> Key: MODPYTHON-195
> URL: http://issues.apache.org/jira/browse/MODPYTHON-195
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.10
>Reporter: Graham Dumpleton
>
> Jeff Robins in:
>
> http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL
> PROTECTED]
> indicates a belief that when an Apache restart is performed on Windows that
> there are a number of Win32 event handles leaked. His belief is that this
> seems to be linked to mod_python.
--
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-197) Problems with how path is calculated by Session class.
Problems with how path is calculated by Session class. -- Key: MODPYTHON-197 URL: http://issues.apache.org/jira/browse/MODPYTHON-197 Project: mod_python Issue Type: Bug Components: session Affects Versions: 3.2.10 Reporter: Graham Dumpleton The code used in the Session class for calculating the path (or domain) of the associated cookie is: # the path where *Handler directive was specified dirpath = self._req.hlist.directory if dirpath: docroot = self._req.document_root() c.path = dirpath[len(docroot):] else: c.path = '/' # Sometimes there is no path, e.g. when Location # is used. When Alias or UserDir are used, then # the path wouldn't match the URI. In those cases # just default to '/' if not c.path or not self._req.uri.startswith(c.path): c.path = '/' This code for calculating the path is sub optimal for a few reasons. The first is that it doesn't work for Location. Second is that it doesn't work for any case where the handler directory falls outside of the document root. There are also problems in as much as it uses req.hlist.directory for trying to determine what the path below the document root may be, when in practice, the value of this isn't necessarily the directory that Python*Handler directive was specified for, as the handler could have been dynamically registered using req.add_handler() with the directory supplied explicitly, in which case req.hlist.directory is merely the first directory to look in for the Python module which implements the handler. Most of the time the result will probably not match the post condition check and so '/' is always used, but at other times it may wrongly validate and be allowed when in fact it could be quite wrong. With the addition of req.hlist.location, more appropriate code for determining the path would be: path = '/' context = req.hlist if context: while context.parent: context = context.parent if context.directory: uri = posixpath.normpath(req.uri) if req.uri[-1] == '/': uri = uri + '/' length = len(req.filename) length -= len(context.directory) - 1 length += len(req.path_info or '') path = uri[:-length] + '/' elif context.location: path = context.location The only problem with this code is that it relies on req.uri/req.filename/req.path_info not having been changed. The value of these could be changed either explicitly by a handler, or by modules such as mod_rewrite. The current mod_python.publisher code even modifies req.filename, although this is out of convenience rather than updating it to pass a modified value to later handler stages. At this point, it is not really clear what should be done about the Session code for calculating the path. Ideally it should always equate to the leading part of the URL which targets the top most directory the handler has been specified for. Whether there is a way of meaningfully determining this in all cases is not clear. As a result, best practice would always be to specify the application domain of the cookie for the session whenever sessions are used. In mod_python 3.3, this is done by using PythonOption to set the mod_python.session.application_domain property. If needing to be compatible with older versions of mod_python as well as mod_python 3.3, should instead use the older ApplicationPath property name with PythonOption. -- 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-193) Add req.hlist.location to mirror req.hlist.directory.
[ http://issues.apache.org/jira/browse/MODPYTHON-193?page=all ] Graham Dumpleton resolved MODPYTHON-193. Resolution: Fixed Implements items 1 and 2, although for 2 only supply req.hlist.location for when Location/LocationMatch directive is actually used. Did not try and synthesise a location when Directory directive is used as process depends on values of req.uri/req.filename/req.path_info, which can be modified by handlers with such modifications giving incorrect results. Did not do item 3. Have also not made changes to Session class as it separately has a number of problems in that section of code and they cannot all be addressed properly. Will open a separate issue for Session path problems. > Add req.hlist.location to mirror req.hlist.directory. > - > > Key: MODPYTHON-193 > URL: http://issues.apache.org/jira/browse/MODPYTHON-193 > Project: mod_python > Issue Type: Improvement > Components: core >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > In mod_python 3.3 a new function is available when the new module importer is > used called apache.get_handler_root(). The purpose of the function is to > return > the directory specified by the Directory directive in which the current > Python*Handler was defined within. In the case of DirectoryMatch being used or > Directory with ~ match, the value returned will always have any wildcards or > regular expressions expanded and will show the true physical directory matched > by Apache for the request. > This function is effectively a wrapper around the value of > req.hlist.directory, > but is actually a bit more complicated than that. The reason there is a bit > more to it than that, is that the function is actually callable while modules > are being imported, ie., outside of the context of the actual request handler. > It is able to be called in this way, as the new importer sets up a per thread > cache where it stashes the information for access for the life of the request. > Further complications arise where req.add_handler() is used and no handler > path > is supplied as last argument to this function. In that case > req.hlist.directory > is None, but the handler path associated with the context in which > req.add_handler() was called can be determined by tracking back through > req.hlist.parent until the directory attribute is specified. To avoid a user > doing this, the value that apache.get_handler_root() returns has already had > that done where necessary. > The reason for making the handler root available when modules are being > imported, as it then makes it a lot easier for web applications to use the > directory that Python*Handler directive was defined for as an anchor point for > the application code, with access to further module imports or config files > being made in respect of this directive dynamically rather than have to hard > code paths in the Apache configuration using PythonOption. In using this > though, one does have to be careful that modules aren't shared between two > handler roots by using PythonInterpreter to separate two distinct web > applications when necessary. > This is all well and good if the Directory/DirectoryMatch directives are used, > but useless if the Location/LocationMatch directives are used. Where these are > currently used, apache.get_handler_root() and req.hlist.directory yield '/'. I > think originally I had the code returning an empty string, but when support > for > expansion of wildcards was added and path normalisation done, the '/' was > getting returned instead. > For starters, instead of '/' the None value should be the result where > Location/LocationMatch directives are used. Second, there should really be an > equivalent to req.hlist.location which yields the leading part or the URL > which > corresponds to the directory stored in req.hlist.directory. In effect this is > yielding an absolute base URL and would mean that it would no longer be > necessary to perform calculations like described in: > http://www.modpython.org/pipermail/mod_python/2006-March/020501.html > for calculating handler base URLs where Directory/DirectoryMatch is used, > something that most people seem to get wrong from what I have seen. > An important thing about that code is that it only works for when > Directory/DirectoryMatch is used. There is actually no way (at least that I > know of), for actually determining what the expanded path corresponding to a > Location/LocationMatch directive is. This is a major grumbling point for > packages like Trac, MoinMoin, Django and TurboGears, as it means that they > have > to require the user to manually duplicate the path to the directive in a > PythonOption or using some other configuration mechanism so that the package > knows where its root URL
[jira] Commented: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[
http://issues.apache.org/jira/browse/MODPYTHON-195?page=comments#action_12444208
]
Graham Dumpleton commented on MODPYTHON-195:
Jeff provides the following further information. The question is whether there
is a more accepted way of doing this now as that email was from two years ago
and that it is dependent on something that change from release to release is a
problem. Maybe a simple static variable can be used to determine if call has
already been made since on the restart, the mod_python module should by rights
be unloaded from memory which means the static should get reset to 0, thus
first call could always be setting it to 1 and second call not doing anything
it already 1.
Anyway, Jeffs email follows:
I added some logging to python_init in mod_python.c to try to understand what
is going on. Apparently when you run apache as a service on win32 the
python_init function gets called TWICE on restart (I have no idea why) and the
first time is somehow spurious (perhaps it is running in the context of the
parent process that spawns the child process that really services requests?)
yet python_init allocates stuff anyway which never gets freed, for example the
"interpreters_lock" allocated via
apr_thread_mutex_create(&interpreters_lock, APR_THREAD_MUTEX_UNNESTED, p);
I found this posting on the web
http://mail-archives.apache.org/mod_mbox/httpd-dev/200311.mbox/[EMAIL PROTECTED]
which seems to agree that the ap_hook_post_config callback gets called twice
on win32 running as a service and suggested this hack:
#ifdef WIN32
/* Do not run post_config in the Windows parent process
* The envar AP_PARENT_PID is set in the env list (by mpm_winnt)
* for the child process.
* **WARNING**:
* This check is not as robust as I would like because the name of
this
* envar is subject to change from release to release.
*/
if (!getenv("AP_PARENT_PID")) {
return OK;
}
#endif
I put this into python_init() just to see what would happen and sure enough,
the leaking 4 handles went away. I don't know what to do at this point since I
am uncomfortable with the hack. Yet clearly python_init() is not expecting to
be called twice on restart. Is this an apache bug or a well-know (heh) feature
that modules must protect themselves against?
> Possible leaking of Win32 event handles when Apache restarted.
> --
>
> Key: MODPYTHON-195
> URL: http://issues.apache.org/jira/browse/MODPYTHON-195
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.10
>Reporter: Graham Dumpleton
>
> Jeff Robins in:
>
> http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL
> PROTECTED]
> indicates a belief that when an Apache restart is performed on Windows that
> there are a number of Win32 event handles leaked. His belief is that this
> seems to be linked to mod_python.
--
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-190) python 2.5 support
[ http://issues.apache.org/jira/browse/MODPYTHON-190?page=all ] Graham Dumpleton updated MODPYTHON-190: --- Fix Version/s: (was: 3.3) Taking this off the list of things to fix in 3.3. We really need someone who has access to Python 2.5 and a 64 bit platform to help us do this one and test it. Until then we could do more harm than good if we start fiddling with the code with no way to actually validate it works ourselves. > python 2.5 support > -- > > Key: MODPYTHON-190 > URL: http://issues.apache.org/jira/browse/MODPYTHON-190 > Project: mod_python > Issue Type: Task > Components: core >Affects Versions: 3.3 > Environment: All >Reporter: Jim Gallacher > Attachments: ssizecheck.diff > > > Python 2.5 has been offically released, The major change that may effect > mod_python is better support for 64-bit machines, allowing for things such as > strings > 2GiB. > Details and conversion guidelines can be found in PEP-353. > http://www.python.org/dev/peps/pep-0353/ > Scanning the mod_python source with the ssizecheck.py script mentioned in the > PEP indicates a number of places that will require attention. -- 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 ] Graham Dumpleton resolved MODPYTHON-93. --- Resolution: Fixed I have looked at the code for this again and to somehow accommodate older versions of Trac is only going to introduce horrible little hacks in mod_python that we don't need, so it just isn't worth the trouble to try and support the older versions. People will simply need to upgrade to at least Trac 0.10.0 if they want to use mod_python 3.3. If the hacks were done, there would be two parts to it. The first is that Trac derives from util.FieldStorage and adds a __setitem__() method. This would need to be overridden from the base class by replacing it with add_field(). def __init__(self, ...): ... self.__setitem__ = self.add_field It has to be done in the constructor and not just as a method, as doing it as a method means derived class overrides it. At that point in the constructor, derived class one is in place and so we effectively replace it. The second part would be more difficult and why it isn't worth the trouble. The problem here is that although the derived class adds __setitem__(), it doesn't itself use it in the derived class constructor. Instead, it does the nasty thing of accessing the base class 'list' attribute directly, thereby duplicating the same code as in __setitem__() that we need to replace. The only way around this nastiness would be for the base class to override the 'append()' method of the 'list' attribute itself and do extra special magic to check for arguments of the old style and change things on the fly, updating the associated index attribute as well. This is just all too messy and magic and would surely come back and bite us. In summary, not worth the trouble. Trac people will just have to upgrade. > Improve util.FieldStorage efficiency > > > Key: MODPYTHON-93 > URL: http://issues.apache.org/jira/browse/MODPYTHON-93 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.2.7 >Reporter: Jim Gallacher > Assigned To: 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] Updated: (MODPYTHON-191) Tampering with signed cookies.
[ http://issues.apache.org/jira/browse/MODPYTHON-191?page=all ] Graham Dumpleton updated MODPYTHON-191: --- Fix Version/s: 3.3 I have marked this as fix for 3.3 as it seems worrying enough that we should address it. Can someone else provide confirmation that it is something that we should worry about and that change is reasonable. > Tampering with signed cookies. > -- > > Key: MODPYTHON-191 > URL: http://issues.apache.org/jira/browse/MODPYTHON-191 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.10 >Reporter: Graham Dumpleton > Fix For: 3.3 > > > As reported by Andy Pearce in: > > http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200609.mbox/[EMAIL > PROTECTED] > Andy Pearce wrote: > > > > Hi, > > > > I think I might have spotted a slight bug in Session.py. When the > > 'secret' parameter is supplied to use the SignedCookie class, it appears > > that __init__ of BaseSession doesn't check the return type of > > get_cookies(). > > > > If I understand the SignedCookie docs correctly, if the cookie value > > doesn't match its signature, it simply returns the contents as a Cookie > > rather than a SignedCookie (indicating that the user tampered with their > > cookie before sending it back). > > > > However, there is no check in BaseSession's __init__ that the return of > > get_cookies() is a SignedCookie in the case that 'secret' is supplied. > > > > Perhaps a minor point, but it would seem to make the option of using > > SignedCookies rather pointless, since the signature isn't being checked. > > Presumably if the cookie has been tampered with, your only safe option > > is to throw it away and generate a new one. I think this can be achieved > > by changing the lines: > > > > if cookies.has_key(session_cookie_name): > > self._sid = cookies[session_cookie_name].value > > > > To something like: > > > > if cookies.has_key(session_cookie_name): > > if not secret or type(cookes[session_cookie_name]) \ > >is Cookie.SignedCookie: > > self._sid = cookies[session_cookie_name].value > > > > I'm fairly new to mod_python, so if I'm mistaken then my apologies, and > > a quick explanation of why would be very much appreciated! ^_^ > > > > Thanks, > > > > - Andy > > > Is this correct and should the change suggested appropriate? -- 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-196) Add req.server.log_error() and req.connection.log_error().
[ http://issues.apache.org/jira/browse/MODPYTHON-196?page=all ] Graham Dumpleton resolved MODPYTHON-196. Resolution: Fixed > Add req.server.log_error() and req.connection.log_error(). > -- > > Key: MODPYTHON-196 > URL: http://issues.apache.org/jira/browse/MODPYTHON-196 > Project: mod_python > Issue Type: New Feature > Components: core >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > In mod_python you can currently log to the Apache error log file using: > apache.log_error() - This is a wrapper around ap_log_error(). By default it > logs against the main Apache server. You can supply an alternate server > object against which to log. Which server object is used is important where > you have different logs files for different virtual servers. > req.log_error() - This is a wrapper around ap_log_rerror(). This logs against > the virtual server the request is being handled within. The output also > includes details about the client from which the request originated. > For completeness, should add: > req.server.log_error() - Also a wrapper around ap_log_error(). Would always > log to the server which the method is called against. > req.connection.log_error() - This would be a wrapper around ap_log_cerror(). > Would log against the virtual server the request is being handled within. > Because it is associated with a particular client, the details of the client > can again be recorded in the logged message. > Note that ap_log_cerror() was only introduced during Apache 2.0.55. As a > result, if an older version of Apache is used than that, instead of using > ap_log_cerror(), it would use ap_log_error() and use > req.connection.base_server as the server to log against. In doing this, the > client information wouldn't be displayed though. -- 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] Work started: (MODPYTHON-196) Add req.server.log_error() and req.connection.log_error().
[ http://issues.apache.org/jira/browse/MODPYTHON-196?page=all ] Work on MODPYTHON-196 started by Graham Dumpleton. > Add req.server.log_error() and req.connection.log_error(). > -- > > Key: MODPYTHON-196 > URL: http://issues.apache.org/jira/browse/MODPYTHON-196 > Project: mod_python > Issue Type: New Feature > Components: core >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > In mod_python you can currently log to the Apache error log file using: > apache.log_error() - This is a wrapper around ap_log_error(). By default it > logs against the main Apache server. You can supply an alternate server > object against which to log. Which server object is used is important where > you have different logs files for different virtual servers. > req.log_error() - This is a wrapper around ap_log_rerror(). This logs against > the virtual server the request is being handled within. The output also > includes details about the client from which the request originated. > For completeness, should add: > req.server.log_error() - Also a wrapper around ap_log_error(). Would always > log to the server which the method is called against. > req.connection.log_error() - This would be a wrapper around ap_log_cerror(). > Would log against the virtual server the request is being handled within. > Because it is associated with a particular client, the details of the client > can again be recorded in the logged message. > Note that ap_log_cerror() was only introduced during Apache 2.0.55. As a > result, if an older version of Apache is used than that, instead of using > ap_log_cerror(), it would use ap_log_error() and use > req.connection.base_server as the server to log against. In doing this, the > client information wouldn't be displayed though. -- 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-196) Add req.server.log_error() and req.connection.log_error().
Add req.server.log_error() and req.connection.log_error(). -- Key: MODPYTHON-196 URL: http://issues.apache.org/jira/browse/MODPYTHON-196 Project: mod_python Issue Type: New Feature Components: core Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 In mod_python you can currently log to the Apache error log file using: apache.log_error() - This is a wrapper around ap_log_error(). By default it logs against the main Apache server. You can supply an alternate server object against which to log. Which server object is used is important where you have different logs files for different virtual servers. req.log_error() - This is a wrapper around ap_log_rerror(). This logs against the virtual server the request is being handled within. The output also includes details about the client from which the request originated. For completeness, should add: req.server.log_error() - Also a wrapper around ap_log_error(). Would always log to the server which the method is called against. req.connection.log_error() - This would be a wrapper around ap_log_cerror(). Would log against the virtual server the request is being handled within. Because it is associated with a particular client, the details of the client can again be recorded in the logged message. Note that ap_log_cerror() was only introduced during Apache 2.0.55. As a result, if an older version of Apache is used than that, instead of using ap_log_cerror(), it would use ap_log_error() and use req.connection.base_server as the server to log against. In doing this, the client information wouldn't be displayed though. -- 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-194) Memory leak due to not clearing thread state object before deletion.
Memory leak due to not clearing thread state object before deletion. Key: MODPYTHON-194 URL: http://issues.apache.org/jira/browse/MODPYTHON-194 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 Jeff Robbins reported a potential memory leak in mod_python as a result of PyThreadState_Clear() not being called prior to PyThreadState_Delete. See: http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL PROTECTED] Problem looks to be valid, but as per followup: http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL PROTECTED] the location of the PyThreadState_Clear() call would need to be moved to before the lock is released. -- 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-171) Assignment to req.filename and POSIX style pathnames.
[ http://issues.apache.org/jira/browse/MODPYTHON-171?page=all ] Graham Dumpleton resolved MODPYTHON-171. Fix Version/s: (was: 3.3) Resolution: Won't Fix Can't auto normalise on assignment to req.filename as detailed so marking this as "won't fix". Will create a separate issue for the idea of creating equivalents to the os.path/posixpath functions which are compatible with working on the Apache POSIXish style paths with allowance for drive letters on Win32, specifically the value of req.filename. > Assignment to req.filename and POSIX style pathnames. > - > > Key: MODPYTHON-171 > URL: http://issues.apache.org/jira/browse/MODPYTHON-171 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.8 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > > In Apache, all the path names relating to the matched target of a request are > dealt with as POSIX style paths. That is, a forward slash is used as the > directory separator even if the platform is Win32. The only real allowance > for Win32 stuff is that drive specifiers may still occur in which case the > drive letter is always converted to upper case. > All the Apache C API functions dealing with manipulation of and specifically > generation of modified paths will by default ensure that paths are maintained > in this POSIX style. To have a path be generated in its true native form, you > need to provide special flags to functions. > When an Apache module writer works with paths, they would normally rely on > the default behaviour and so long as they use the functions provided by the > Apache C API, the result will always be consistent. > Where would all this be a potential issue is where modules set the > request_rec->filename attribute, ie., the req.filename attribute of the > mod_python request object. In a C Apache module, as the result is always > going to be in the correct form when request_rec->filename is modified, > everything still comes out okay. > The problem in mod_python, or more perhaps when using Python, is that all the > directory manipulation routines in os.path as they exist on Win32 platform > can generate paths with back slashes in them. Further, it is often convenient > to use __file__ attribute of modules in some way, which again is going to use > back slashes on Win32 platform. If the results from either of these is > assigned to req.filename, the result request_rec->filename attribute is no > longer going to be in the POSIX style form which is would normally exist if > only the Apache C APIs were used. > One area where this causes a problem (and which isn't fixed) was described in > MODPYTHON-161, whereby setting req.filename to a path which includes back > slashes instead of the required POSIX style forward slashes can result in the > wrong interpreter being selected for a subsequent phase if the > PythonInterpPerDirectory directive is being used. The case used for any drive > specifier could similarly be a problem. > Now although Python provides os.path.normpath(), that normalises a path in > the native format. There is no function which can normalise a path and output > it in the POSIX style format. Trying to create a function in Python which > does may not yield the same result as what Apache expects. > The actual function in Apache which can be used to normalise paths and which > outputs the POSIX style path required is apr_filepath_merge(). The question > is, should this be exposed in some way so that it is useable from mod_python, > or for the req.filename case, should assignment to req.filename automatically > trigger normalisation of the path to ensure that it simply just works all the > time and isn't dependent on a user of mod_python realising they need to > normalise it first in the POSIX style to ensure their code is portable across > platforms. -- 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-191) Tampering with signed cookies.
Tampering with signed cookies. -- Key: MODPYTHON-191 URL: http://issues.apache.org/jira/browse/MODPYTHON-191 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton As reported by Andy Pearce in: http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200609.mbox/[EMAIL PROTECTED] Andy Pearce wrote: > > Hi, > > I think I might have spotted a slight bug in Session.py. When the > 'secret' parameter is supplied to use the SignedCookie class, it appears > that __init__ of BaseSession doesn't check the return type of > get_cookies(). > > If I understand the SignedCookie docs correctly, if the cookie value > doesn't match its signature, it simply returns the contents as a Cookie > rather than a SignedCookie (indicating that the user tampered with their > cookie before sending it back). > > However, there is no check in BaseSession's __init__ that the return of > get_cookies() is a SignedCookie in the case that 'secret' is supplied. > > Perhaps a minor point, but it would seem to make the option of using > SignedCookies rather pointless, since the signature isn't being checked. > Presumably if the cookie has been tampered with, your only safe option > is to throw it away and generate a new one. I think this can be achieved > by changing the lines: > > if cookies.has_key(session_cookie_name): > self._sid = cookies[session_cookie_name].value > > To something like: > > if cookies.has_key(session_cookie_name): > if not secret or type(cookes[session_cookie_name]) \ >is Cookie.SignedCookie: > self._sid = cookies[session_cookie_name].value > > I'm fairly new to mod_python, so if I'm mistaken then my apologies, and > a quick explanation of why would be very much appreciated! ^_^ > > Thanks, > > - Andy > Is this correct and should the change suggested appropriate? -- 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-116) Attributes removed from module code file still accessible until restart.
[ http://issues.apache.org/jira/browse/MODPYTHON-116?page=all ] Graham Dumpleton resolved MODPYTHON-116. Fix Version/s: 3.3 Resolution: Fixed Resolved by new module importer for 3.3, but for 3.3 release looks like the new importer will have to be enabled explicitly as will not be the default. Note though that in the new module importer, when modules are reloaded they are loaded into an empty module object. As a consequence, by default any state held as global data in the existing module in memory will be lost. The new importer does though allow hooks to be provided for the purpose of transferring state from the existing module in memory to the new module when it is being loaded. > Attributes removed from module code file still accessible until restart. > > > Key: MODPYTHON-116 > URL: http://issues.apache.org/jira/browse/MODPYTHON-116 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.7, 3.1.4 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > When using "apache.import_module()" directly, or when it is used indirectly > by the "Python*Handler" directives, and automatic module reloading occurs, > modules are reloaded on top of the existing module. One of the problems with > this is that if an attribute such as a function or data value is removed from > the code file on disk, when the module is reloaded, that attribute doesn't > get removed from the in memory module held by mod_python. The only way to > eliminate such an attributed from the in memory module currently is to > restart Apache, automatic module reloading doesn't help. > A good example of the problems this can cause is with mod_python.publisher. > Because attributes can be arbitrarily mapped to by a URL, if you forget to > prefix variables or functions with an underscore they will be visible to a > request. If such a mistake was realised and you change the source code to add > an underscore prefix and relied on automatic module reloading, it wouldn't > actually get rid of the incorrectly named attribute in the module held in the > mod_python cache. Thus, the restart of Apache is still required. > As it stands for mod_python.publisher, the problem is fixed in 3.2.6, but it > still exists for direct use of "apache.import_module()" and "Python*Handler" > directives. The consequences outside of mod_python.publisher may not be as > problematic, bu depends on specific user code. > A scheme whereby new modules are reloaded into a new module instance would > eliminate this 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] Resolved: (MODPYTHON-115) import_module() and multiple modules of same name.
[ http://issues.apache.org/jira/browse/MODPYTHON-115?page=all ] Graham Dumpleton resolved MODPYTHON-115. Fix Version/s: 3.3 Resolution: Fixed Resolved by new module importer for 3.3, but for 3.3 release looks like the new importer will have to be enabled explicitly as will not be the default. In the new module importer, modules are not stored in sys.module and instead are stored in a separate caching system where they are distinguished by the full pathname to the module file. Note though that the new module importer doesn't work with Python packages. Python packages must be in a directory appearing on sys.path and when needed will be imported by standard Python import mechanism. Any Python packages will not be candidates for automatic reloading and because they will still be stored in sys.modules, must have a unique top level name for the package. > import_module() and multiple modules of same name. > -- > > Key: MODPYTHON-115 > URL: http://issues.apache.org/jira/browse/MODPYTHON-115 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.1.4, 3.2.7 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > The "apache.import_module()" function is a thin wrapper over the standard > Python module importing system. This means that modules are still stored in > "sys.modules". As modules in "sys.modules" are keyed by their module name, > this in turn means that there can only be one active instance of a module for > a specific name. > The "import_module()" function tries to work around this by checking the path > name of the location of a module against that being requested and if it is > different will reload the correct module. This check of the path though only > occurs when the "path" argument is actually supplied to the "import_module()" > function. The "path" is only supplied in this way when mod_python.publisher > makes use of the "import_module()" function, it is not supplied when the > "Python*Handler" directives are used because in that circumstance a module > may actually be a system module and supplying "path" would prevent it from > being found. > Even though mod_python.publisher supplies the "path" argument to the > "import_module()" function, the check of the path has bugs, with modules > possibly becoming inaccessible as documented in JIRA as MODPYTHON-9. > The check by mod_python of the path name to the actual code file for a module > to determine if it should be reloaded, can also cause a continual cycle of > module reloading even though the modules on disk may not have changed. This > will occur when successive requests alternate between URLs related to the > distinct modules having the same name. This cyclic reloading is documented in > JIRA as MODPYTHON-10. > That a module is reloaded into the same object space as the existing module > when two modules of the same name are in different locations, can also cause > namespace pollution and security issues if one location for the module was > public and the other private. This cross contamination of modules is as > documented in JIRA as MODPYTHON-11. > In respect of the "Python*Handler" directives where the "path" argument was > never supplied to the "import_module()" function, the result would be that > the first module loaded under the specified name would be used. Thus, any > subsequent module of the same name referred to by a "Python*Handler" > directive found in a different directory but within the same interpreter > would in effect be ignored. > A caveat to this though is that such a "Python*Handler" directive would > result in that handlers directory being inserted at the head of "sys.path". > If the first instance of the module loaded under that name were at some point > modified, the module would be automatically reloaded, but it would load the > version from the different directory. > Now, although these problem as they relate to mod_python.publisher are > addressed in mod_python 3.2.6, the underlying problems in 'import_module()' > are not. As the bug reports as they relate to mod_python.publisher have been > closed off as resolved, am creating this bug report so as to carry on a bug > report for the underlying problem as it applies to "Python*Handler" directive > and use of "import_module()" explicitly. > To illustrate the issue as it applies to "Python*Handler" directive, create > two separate directories with a .htaccess file containing: > AddHandler mod_python .py > PythonHandler index > PythonDebug On > In the "index.py" file in each separate directory put: > import os > from mod_python import apache > def handler(req): > req.content_type = 'text/plain' > print >> req, os.getpid(), __file__ > return apache.OK
[jira] Resolved: (MODPYTHON-54) Add a way to import a published page into another published page
[ http://issues.apache.org/jira/browse/MODPYTHON-54?page=all ]
Graham Dumpleton resolved MODPYTHON-54.
---
Resolution: Fixed
Resolved by new module importer for 3.3, but for 3.3 release looks like the new
importer will have to be enabled explicitly as will not be the default.
With the new importer, the existing apache.import_module() function should be
used as mod_python.publisher will also use that itself and thus all modules are
loaded via the same module caching system.
> Add a way to import a published page into another published page
>
>
> Key: MODPYTHON-54
> URL: http://issues.apache.org/jira/browse/MODPYTHON-54
> Project: mod_python
> Issue Type: Improvement
> Components: importer
>Affects Versions: 3.2.7
>Reporter: Nicolas Lehuen
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> Before mod_python 3.2, standard Python modules and published modules could be
> imported the same way, using apache.import_module. This had a number of
> disadvantages, leading to MODPYTHON-8, MODPYTHON-9, MODPYTHON-10,
> MODPYTHON-11 and MODPYTHON-12.
> All these bugs were fixed by separating the published modules from the
> standard Python module. apache.import_module can still be used to import
> standard modules, but published modules are now fully managed by
> mod_python.publisher, and are not inserted into sys.modules.
> The problem is that there is a use case of importing a published module from
> another published module :
> /index.py
> def index(req):
> return "Hello, world !"
> def utility_function(foobar):
> return foobar+1
> /other.py
> import os
> directory = os.path.split(__file__)[0]
> other_index = apache.import_module("index",path=[directory])
> def index(req):
> return "%s %i"%(other_index.index(req),other_index.utility_function(2004))
> This was alread a bit of a hack in 3.1.4, but in 3.2 it does not really work
> the expected way since the imported module (other_index in the example) is
> not the same module as the one the publisher would use to publish /index.py.
> This could be troublesome if the developer wanted to share some data between
> the modules, e.g. a cache or a connection pool, but not if he only wanted to
> share some code.
> Therefore, we need to provide a clean API in mod_python.publisher to allow
> developers to reference another published module.
--
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-8) Improve apache.load_module with a two-level locking scheme
[ http://issues.apache.org/jira/browse/MODPYTHON-8?page=all ] Graham Dumpleton resolved MODPYTHON-8. -- Resolution: Fixed Resolved by new module importer for 3.3, but for 3.3 release looks like the new importer will have to be enabled explicitly as will not be the default. > Improve apache.load_module with a two-level locking scheme > -- > > Key: MODPYTHON-8 > URL: http://issues.apache.org/jira/browse/MODPYTHON-8 > Project: mod_python > Issue Type: Improvement > Components: importer >Affects Versions: 3.1.3 >Reporter: Nicolas Lehuen > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > We should rewrite apache.load_python with a two level locking scheme, in > order to reduce thread contention when using the threading MPM. > I've already implemented something similar for a custom-made publisher system > (comparable to Graham's Vampire) ; I've used a thread-safe caching system > that I've donated to the Python Cookbook : > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302997 > Maybe this should be experimented in a separate branch, and merged back once > we're sure that everything works perfectly ? -- 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-143) Implement and integrate a new module importer.
[ http://issues.apache.org/jira/browse/MODPYTHON-143?page=comments#action_12427684 ] Graham Dumpleton commented on MODPYTHON-143: This issue is basically complete and is just lacking some documentation. The name of the PythonOption setting was never changed and is still mod_python.future.importer. As stated before, to enable use of new importer for all Python interpreter instances, in other words for everything, will be necessary to specify: PythonOption mod_python.future.importer * To enable use of the new importer for selected Python interpreter instances, instead of "*" a comma separated list of interpreter names can be specified. Thus, to enable for a single interpreter called "testing-1", use: PythonOption mod_python.future.importer testing-1 Or for both "testing-1" and "testing-2" interpreters, use: PythonOption mod_python.future.importer testing-1,testing-2 In all cases, the PythonOption must be in the main Apache configuration files outside of any VirtualHost, Directory, Files or Location directives. It still looks like use of this new importer will be optional in mod_python 3.3 and enabled as default only in some subsequent version. > Implement and integrate a new module importer. > -- > > Key: MODPYTHON-143 > URL: http://issues.apache.org/jira/browse/MODPYTHON-143 > Project: mod_python > Issue Type: Task > Components: importer >Affects Versions: 3.2.8 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > > This is an overall task to cover the issue of rectifying the various module > importer issues by replacing it with a new implementation. A description of > the various problems can be found in: > http://www.dscpl.com.au/articles/modpython-003.html > Separate issues had already been created for some of the specific problems. > These issues will now be linked to this problem and thus marked as being > dependent on this issue. > In other words, replacing the module importer will solve a number of number > issues. Rather than try and keep up to date all the separate issues, all > information about the replacement will be put against this issue instead. > Note that there are also some issues which are not directly related to the > module importer but which will be made dependent on this issue because it is > easier to fix the issue as part of the rewrite of the module importer and top > level handler dispatch mechanism than it is to address it as a distinct item. > In respect of what impacts the new module importer implementation may have > and how it is used may change, this will be documented in the following > document for the time being: > http://www.dscpl.com.au/articles/modpython-007.html > Note that this document is a work in progress. It is dense reading and > assumes you know a bit about the current module importer and its problems. > Any significant issues raised by this document can be added here as a > comment, or if a general dicussion of a topic is needed, raise the issue on > the mod_python developers mailing list. > A possible new implementation for the module importer is basically ready for > testing and experimentation. The intent is to push it into the mod_python > source tree, but for its use to be optional. > If wanting to enable it for a specific Python interpreter, the PythonImport > directive would be used: > PythonImport mod_python.future.importer mytestinterpreter > If wanting to enable it for all Python interpreters, a PythonOption directive > would be used at global scope within the Apache configuration. Ie., outside > of all Location, Directory or Files container directives. The exact option > name to be used hasn't yet been decided. > More details and announcements at the appropriate time. -- 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-174) Update requirements to Apache 2.0.47 or greater
[ http://issues.apache.org/jira/browse/MODPYTHON-174?page=all ] Graham Dumpleton updated MODPYTHON-174: --- Fix Version/s: 3.3 3.2.10 (was: 3.2.x) > Update requirements to Apache 2.0.47 or greater > --- > > Key: MODPYTHON-174 > URL: http://issues.apache.org/jira/browse/MODPYTHON-174 > Project: mod_python > Issue Type: Task > Components: documentation >Affects Versions: 3.2.7, 3.2.8, 3.2.x >Reporter: David Fraser > Assigned To: Jim Gallacher > Fix For: 3.3, 3.2.10 > > Attachments: apache-2.0.47-req-doc.patch > > > Usage of the apr_table_compress function requires Apache 2.0.47, but the docs > only specify version 2.0.40 > See the following URLs for details > http://www.modpython.org/pipermail/mod_python/2006-February/020280.html > http://www.modpython.org/pipermail/mod_python/2006-May/021135.html > http://www.modpython.org/pipermail/mod_python/2006-May/021133.html > More details: apr_table_compress was was committed in r263916 to mod_python.c > Log message: > Fixed crash and memory leak in python_merge_config function in mod_python.c > described in MODPYTHON-75. Boyan Boyadjiev provided the code which corrected > the problem. This also fixes the memory leak resulting in the use of any > PythonOption directive as described in MODPYTHON-60. -- 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-173) DbmSession creates world readable db file
[ http://issues.apache.org/jira/browse/MODPYTHON-173?page=all ] Graham Dumpleton updated MODPYTHON-173: --- Fix Version/s: 3.2.10 (was: 3.2.x) > DbmSession creates world readable db file > - > > Key: MODPYTHON-173 > URL: http://issues.apache.org/jira/browse/MODPYTHON-173 > Project: mod_python > Issue Type: Bug > Components: session >Affects Versions: 3.2.8 >Reporter: Jim Gallacher > Assigned To: Jim Gallacher > Fix For: 3.3, 3.2.10 > > > 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] Updated: (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=all ] Graham Dumpleton updated MODPYTHON-172: --- Fix Version/s: 3.2.10 > 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/" > > AddHandler mod_python .py > PythonHandler pyHandlerHTTP > PythonDebug On > > = > 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] Updated: (MODPYTHON-137) Add req.server.get_options() for obtain PythonOption values set at global level.
[ http://issues.apache.org/jira/browse/MODPYTHON-137?page=all ] Graham Dumpleton updated MODPYTHON-137: --- Fix Version/s: 3.2.10 > Add req.server.get_options() for obtain PythonOption values set at global > level. > > > Key: MODPYTHON-137 > URL: http://issues.apache.org/jira/browse/MODPYTHON-137 > Project: mod_python > Issue Type: New Feature > Components: core >Affects Versions: 3.3 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3, 3.2.10 > > Attachments: grahamd_20060228_MP137_1.diff > > > The req.server.get_config() member seems like it is supposed to allow access > to values of configuration directives set at global context. It seems though > to have a few problems with it though. See MODPYTHON-133 and MODPYTHON-134. > Regardless of that, it seems it may be appropriate to provide an equivalent > for PythonOption directive settings. Specifically req.server.get_options(). > This would return a table object giving all PythonOption value settings > performed at global scope. This would be useful where a value needs to be set > globally in one place and not be overridable in more constrained > configuration containers. > This might for example be used as a way or allowing the mutex directory to be > specified in the Apache configuration as well as as a "configure" command > line option. See MODPYTHON-131. > See commentary along with some patches in: > http://www.mail-archive.com/python-dev@httpd.apache.org/msg01295.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-145) Make number of mutex locks configurable at apache startup
[ http://issues.apache.org/jira/browse/MODPYTHON-145?page=all ] Graham Dumpleton updated MODPYTHON-145: --- Fix Version/s: 3.2.10 > Make number of mutex locks configurable at apache startup > - > > Key: MODPYTHON-145 > URL: http://issues.apache.org/jira/browse/MODPYTHON-145 > Project: mod_python > Issue Type: New Feature > Components: core >Affects Versions: 3.3 >Reporter: Jim Gallacher > Assigned To: Jim Gallacher >Priority: Minor > Fix For: 3.3, 3.2.10 > > > The number of locks can already be specified at compile time usine > ./configure --with-max-locks=value > For completeness, the maximum number of mutex locks created by python_init > should be configurable via a PythonOption. The number of locks will only be > set if the PythonOption directive appears in the server context. Any other > context will be ignored. > PythonOption mod_python.mutex_locks value > The implementation of this will be similar to the code required for > http://issues.apache.org/jira/browse/MODPYTHON-131. > The number of locks can already be specified at compile time usine > ./configure --with-max-locks=value -- 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-131) Make name of mutex directory configurable.
[ http://issues.apache.org/jira/browse/MODPYTHON-131?page=all ] Graham Dumpleton updated MODPYTHON-131: --- Fix Version/s: 3.2.10 > Make name of mutex directory configurable. > -- > > Key: MODPYTHON-131 > URL: http://issues.apache.org/jira/browse/MODPYTHON-131 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.2.7 >Reporter: Graham Dumpleton > Assigned To: Jim Gallacher > Fix For: 3.3, 3.2.10 > > > 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] Updated: (MODPYTHON-122) configure fails when using bash 3.1.x
[ http://issues.apache.org/jira/browse/MODPYTHON-122?page=all ] Graham Dumpleton updated MODPYTHON-122: --- Fix Version/s: 3.3 3.2.10 (was: 3.2.x) > configure fails when using bash 3.1.x > - > > Key: MODPYTHON-122 > URL: http://issues.apache.org/jira/browse/MODPYTHON-122 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.1.4, 3.2.7 > Environment: Any platform using bash 3.1.x >Reporter: Jim Gallacher > Assigned To: Jim Gallacher >Priority: Minor > Fix For: 3.3, 3.2.10 > > > 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 ]
Graham Dumpleton updated MODPYTHON-119:
---
Fix Version/s: 3.3
3.2.10
(was: 3.2.x)
> DBM Session test shouldn't use default database.
>
>
> Key: MODPYTHON-119
> URL: http://issues.apache.org/jira/browse/MODPYTHON-119
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.7
>Reporter: Graham Dumpleton
> Assigned To: Jim Gallacher
> Fix For: 3.3, 3.2.10
>
>
> 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] Updated: (MODPYTHON-94) Calling APR optional functions provided by mod_ssl
[ http://issues.apache.org/jira/browse/MODPYTHON-94?page=all ] Graham Dumpleton updated MODPYTHON-94: -- Fix Version/s: 3.2.10 > Calling APR optional functions provided by mod_ssl > -- > > Key: MODPYTHON-94 > URL: http://issues.apache.org/jira/browse/MODPYTHON-94 > Project: mod_python > Issue Type: New Feature > Components: core > Environment: Apache 2 >Reporter: Deron Meranda > Assigned To: Graham Dumpleton > Fix For: 3.3, 3.2.10 > > Attachments: modpython4.tex.patch, requestobject.c.patch > > > mod_python is not able to invoke APR Optional Functions. There are > some cases however where this could be of great benifit. > For example, consider writing an authentication or authorization handler > which needs to determine SSL properties (even if to just answer the > simple question: is the connection SSL encrypted). The normal way of > looking in the subprocess_env for SSL_* variables does not work in those > early handler phases because those variables are not set until the fixup > phase. > The mod_ssl module though does provide both a ssl_is_https() and > ssl_var_lookup() optional functions which can be used in earlier > phases. For example look at how mod_rewrite calls those; using > the APR_DECLARE_OPTIONAL_FN and APR_RETRIEVE_OPTIONAL_FN > macros. > I can see how it might be very hard to support optional functions in > general because of the C type linkage issue, but perhaps a select few > could be coded directly into mod_python. -- 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-183) Stop Python directives being used in .htaccess files.
Stop Python directives being used in .htaccess files. - Key: MODPYTHON-183 URL: http://issues.apache.org/jira/browse/MODPYTHON-183 Project: mod_python Issue Type: New Feature Components: core Reporter: Graham Dumpleton When changes to support use of wildcards in conjunction with the Directory directive (as described in MODPYTHON-63), and use of DirectoryMatch or ~ with the Directory directive are also supported, it will be possible to say something like: AddHandler mod_python .py PythonHandler mod_python.publisher PythonInterpPerDirective On PythonDebug on Such a setup will allow for a form of automatic mass hosting where it is not necessary to specify the directives for every user manually. Further, the use of the PythonInterpPerDirective directive will mean that each users code is isolated within their own Python interpreter instance. How well this will scale is another issue, but it will be possible to do. The problem with this is that if the user is still able to make use of a .htaccess file, then it is possible for them to override these directives to make it do something entirely different, or even override which Python interpreter instance is used and force their handlers to run within the context of another users Python interpreter. If an administrator wants to be able to force that things are done in a specific way, but still allow some level of control by a user using a .htaccess file, then a way is needed of specifying from the main Apache configuration file that a user .htaccess file is not allowed to override the behaviour of different aspects of mod_python. This could be achieved by implementing a new directive called PythonAllowOverride. The simplest argument to this directive would be: PythonAllowOverride None By specifying this in the main Apache configuration file, it would prevent the use of any mod_python related directives in .htaccess files. In addition, since mod_python allows everything to be overridden by default anyway, one could use a subtractive approach to allow specific features to be prohibited from being overridden in a .htaccess file. For example: PythonAllowOverride -Interpreter This would have the affect of prohibiting the use of PythonInterpreter, PythonInterpPerDirectory and PythonInterpPerDirective. One could also prohibit any handlers being specified in a .htaccess file using: PythonAllowOverride -Handlers Rather than prohibiting all handlers, one could allow each to be enumerated. PythonAllowOverride -AccessHandler -AuthenHandler -AuthzHandler This particular case would be quite important, as at the moment there is potential for a user to override a site wide security scheme by specifying their own authentication handler that replaces the site wide security and just lets everyone in. Allowing a user to use the PythonOption directive could also be prohibited. PythonAllowOverride -Options Not allowing them to specify any options at all though might be a bit draconian, but you might want to at least prohibit them from setting certain options. For example, when mod_python is fixed so as to always use a 'mod_python.' prefix for its own options, you might specify: PythonAllowOverride -Options=mod_python.* By doing this, you would prohibit a user for overriding options related to sessions for example and thereby screwing things up. The syntax for this one may need to be different, or even perhaps supported by a separate directive for this purpose. It should be noted though, that a users handler could still set options from within the handler itself, but the important thing is that no options would have played havoc with handlers for earlier phases such as authentication phases in cases where allowing a user to specify a handler for the earlier phase was prohibited. Other things that could be selectively prohibit are: PythonAllowOverride -Path PythonAllowOverride -AutoReload PythonAllowOverride -Debug All in all, something like this directive is needed to make mod_python more attractive in environments where an extra level of control is required such as shared hosting or even company systems where users are allowed to specify their own web pages/handlers. -- 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] Work started: (MODPYTHON-164) Allow req.add_handler()/req.register_*_filter() to take module/function for handler.
[ http://issues.apache.org/jira/browse/MODPYTHON-164?page=all ]
Work on MODPYTHON-164 started by Graham Dumpleton.
> Allow req.add_handler()/req.register_*_filter() to take module/function for
> handler.
>
>
> Key: MODPYTHON-164
> URL: http://issues.apache.org/jira/browse/MODPYTHON-164
> Project: mod_python
> Issue Type: New Feature
> Components: core
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
>
> Currently, the:
> req.add_handler(phase, handler, dir)
> req.register_input_filter(filter_name, filter, dir)
> req.register_output_filter(filter_name, filter, dir)
> functions require the handler/filter to be a string. This string identifies
> the module that should be imported and which contains the necessary function,
> plus optionally, an alternate named function to the default for the phase or
> filter type. For example:
> req.add_handler("PythonHandler", "mymodule::myhandler")
> It would be simpler if the handler/filter argument could be overloaded and
> instead supplied an actual module reference or callable object reference. For
> example:
> import mymodule
> def myhandler(req):
> ...
> def fixuphandler(req):
> req.add_handler("PythonHandler", mymodule)
> req.add_handler("PythonHandler", mymodule.myhandler)
> req.add_handler("PythonHandler", myhandler)
> return apache.OK
> This would be easier than having to construct a string module/function
> reference when you have direct access to the handler function.
> In the main the "dir" argument would be irrelevant. The only circumstance
> where it would matter is where PythonInterpPerDirective was used as it could
> be used to control the interpreter the code executed within. If not supplied,
> it could be argued that the directory where the supplied module/function is
> defined in should be used as "dir".
--
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-164) Allow req.add_handler()/req.register_*_filter() to take module/function for handler.
[ http://issues.apache.org/jira/browse/MODPYTHON-164?page=all ]
Graham Dumpleton reassigned MODPYTHON-164:
--
Assignee: Graham Dumpleton
> Allow req.add_handler()/req.register_*_filter() to take module/function for
> handler.
>
>
> Key: MODPYTHON-164
> URL: http://issues.apache.org/jira/browse/MODPYTHON-164
> Project: mod_python
> Issue Type: New Feature
> Components: core
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
>
> Currently, the:
> req.add_handler(phase, handler, dir)
> req.register_input_filter(filter_name, filter, dir)
> req.register_output_filter(filter_name, filter, dir)
> functions require the handler/filter to be a string. This string identifies
> the module that should be imported and which contains the necessary function,
> plus optionally, an alternate named function to the default for the phase or
> filter type. For example:
> req.add_handler("PythonHandler", "mymodule::myhandler")
> It would be simpler if the handler/filter argument could be overloaded and
> instead supplied an actual module reference or callable object reference. For
> example:
> import mymodule
> def myhandler(req):
> ...
> def fixuphandler(req):
> req.add_handler("PythonHandler", mymodule)
> req.add_handler("PythonHandler", mymodule.myhandler)
> req.add_handler("PythonHandler", myhandler)
> return apache.OK
> This would be easier than having to construct a string module/function
> reference when you have direct access to the handler function.
> In the main the "dir" argument would be irrelevant. The only circumstance
> where it would matter is where PythonInterpPerDirective was used as it could
> be used to control the interpreter the code executed within. If not supplied,
> it could be argued that the directory where the supplied module/function is
> defined in should be used as "dir".
--
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-169) Add feature to allow mod_python to be an auth provider.
[
http://issues.apache.org/jira/browse/MODPYTHON-169?page=comments#action_12423609
]
Graham Dumpleton commented on MODPYTHON-169:
At the same time as looking into how to allow mod_python to act as an auth
provider, should also look into how mod_python can be allowed to use an auth
provider. For example req.check_password() and req.get_realm_hash() methods
which call through to whatever the auth provider is defined as for mod_python's
use. This would probably need a new directive called AuthPythonProvider which
would be used as:
AuthPythonProvider dbm
AuthDBMType SDBM
AuthDBMUserFile /www/etc/dbmpasswd
In other words, the Apache directive external to Python code specifies to what
auth provider the request methods get redirected.
> Add feature to allow mod_python to be an auth provider.
> ---
>
> Key: MODPYTHON-169
> URL: http://issues.apache.org/jira/browse/MODPYTHON-169
> Project: mod_python
> Issue Type: New Feature
> Components: core
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
>
> In Apache 2.2, the implementation of authentication has been split into two
> parts. The first is that which handles the specifics of negotiating with a
> client for a specific authentication mechanism type, for example, Basic or
> Digest authentication. The second part is that which handles the specifics of
> verifying the actual users credentials, for example, by looking the user up
> in a dbm database, ldap or some other type of user database.
> The second part of this is referred to as the auth provider and in Apache 2.2
> it is possible to hook in additional providers. This means that the any
> builtin support in Apache for Basic and Digest authentication mechanism can
> be used, but the verification could be done by some arbitrary user code. Such
> verification could be done in Python, if mod_python allowed one to define the
> necessary auth provider hooks.
> To this end, proposed that mod_python be extended such that when using Apache
> 2.2, that it is possible to say:
> AuthType Basic
> AuthName "Restricted Files"
> AuthBasicProvider mod_python
> PythonAuthBasicProvider somemodule
> or:
> AuthType Digest
> AuthName "Restricted Files"
> AuthDigestProvider mod_python
> PythonAuthDigestProvider somemodule
> That is, by specifying mod_python in conjunction with AuthBasicProvider or
> AuthDigestProvider directives, it triggers mod_python to be given option of
> satisfying need to perform verification of user credentials. The function to
> be called for each being given by the PythonAuthBasicProvider and
> PythonAuthDigestProvider respectively.
> The argument to these directives would be a module name, in which case a
> function of the name "authbasicprovider" or "authdigestprovider" will be
> expected to exist. If wanting to specify a particular module, like in handler
> directives, would also be possible to say:
> PythonAuthBasicProvider somemodule::check_password
> PythonAuthDigestProvider somemodule::get_realm_hash
> Note that the prototype of the function for each would not be like existing
> handlers and is different in each case. For the Basic auth mechanism, an
> example function would be:
> users = { ... }
> def authbasicprovider(req, user, password):
> # could consult req.auth_name() to get realm
> if user not in users:
> return apache.AUTH_USER_NOT_FOUND
> # assuming passwords are stored in clear text
> if users[user] != password:
> return apache.AUTH_DENIED
> return apache.AUTH_GRANTED
> Exceptions would be translated into apache.AUTH_GENERAL_ERROR, or function
> could explicitly return it. Could also allow explicit exception of type
> apache.SERVER_RETURN like in handlers but where argument is auth values.
> For Digest authentication, function would be:
> def authdigestprovider(req, user, realm):
> # could select database based on 'realm'
> if user not in users:
> return None
> # assuming passwords are stored in clear text
> return md5.new("%s:%s:%s" % (user, realm, users[user])).hexdigest()
> In this later function, return None indicates apache.AUTH_USER_NOT_FOUND. An
> apache.SERVER_RETURN exception could also be used with that value as
> argument. Returning of an actual string would imply apache.AUTH_USER_FOUND.
> Unexpected exceptions taken as apache.AUTH_GENERAL_ERROR, or could be raised
> explicitly using apache.SERVER_RETURN exception.
> What all this would mean is that you would never need to write an
> authenhandler again using mod_python, as you could rely on any type of
> authenhandler builtin to Apache or as as supported by some third party Apache
> module. All you would need to do is supply the auth provider or Basic or
> Digest authentication as necessary to suppor
[jira] Commented: (MODPYTHON-104) Allow Python code callouts with mod_include (SSI).
[ http://issues.apache.org/jira/browse/MODPYTHON-104?page=comments#action_12378409 ] Graham Dumpleton commented on MODPYTHON-104: The Apache crash when a Python exception occurs has been eliminated, but at the same time have disabled details of any Python exception being rendered into any page sent as result to client even if PythonDebug is On. The rendered page will show the message: [an error occurred while processing this directive] which seems to be more consistent with how SSI handlers work. If found that mod_perl as a comparison, does in some cases render details of exception into page, then maybe this can be changed back at some point. Note that although the crash has been eliminated, it can still be triggered if filter.disable() is called from Python code executed from SSI code somehow. There perhaps need to be some flag maintained in mod_python filterobject so that the context in which the filter_rec wrapper is used is known and for filter.disable() to only do something when used for an input/output filter and not in other use cases. Other functions of filter object need to be reviewed to see if they might cause other problems if used from an include filter. > 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: > > > 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] Resolved: (MODPYTHON-101) If target handler found but evaluates false, there should still be an error if not silent.
[ http://issues.apache.org/jira/browse/MODPYTHON-101?page=all ]
Graham Dumpleton resolved MODPYTHON-101:
Fix Version: 3.3
Resolution: Fixed
> If target handler found but evaluates false, there should still be an error
> if not silent.
> --
>
> Key: MODPYTHON-101
> URL: http://issues.apache.org/jira/browse/MODPYTHON-101
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2.7, 3.1.4
> Reporter: Graham Dumpleton
> Assignee: Graham Dumpleton
> Fix For: 3.3
>
> If one specifies PythonHandler directive and the target is mistakenly set to
> be something like:
> handler = 0
> handler = None
> handler = False
> handler = []
> handler = {}
> no error is raised.
> As comparison, if one has:
> handler = 1
> you get an error:
> Traceback (most recent call last):
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py",
> line 309, in HandlerDispatch
> result = object(req)
> TypeError: 'int' object is not callable
> This is because if the target in any way evaluates to false, no attempt is
> made to execute it, but at the same time if the silent flag is not set no
> error is raised either.
> In the case of HandlerDispatch in apache.py, the code currently is:
> # find the object
> object = resolve_object(module, object_str,
> arg=req, silent=hlist.silent)
>
> if object:
>
> # call the object
>
> elif hlist.silent:
> result = DECLINED
>
> It would make more sense that if hlist.silent is not set, that the object,
> whatever it may be should be called. This would ensure that any error
> response is always generated when it can be.
> Thus, instead of just:
> if object:
> it should really be:
> if not hlist.silent or object:
> In the case of ConnectionDispatch() and FilterDispatch(), because silent is
> fixed to "0" in those cases, there should not even be a check of whether
> object evaluates true, it should just be called regardless.
> Thus instead of:
> if object:
> # call the object
> if config.has_key("PythonEnablePdb"):
> result = pdb.runcall(object, conn)
> else:
> result = object(conn)
> it should just be:
> # call the object:
> if config.has_key("PythonEnablePdb"):
> result = pdb.runcall(object, conn)
> else:
> result = object(conn)
> Indent level of following assertion clause in case of ConnectionDispatch()
> and call to filter.flush() in FilterDispatcher() should also be shifted out
> as well as appropriate.
--
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-162) Add means of optionally merging handlers from parent context into a child context.
[ http://issues.apache.org/jira/browse/MODPYTHON-162?page=comments#action_12374919 ] Graham Dumpleton commented on MODPYTHON-162: Note that the hardest part of implementing this is working out what interpreter handlers should be executed within when they are merged. If PythonInterpreter is set, then whatever that value for the directory the request is made against would be used. If PythonInterpPerDirectory is used, then interpreter named is based on req.filename. If req.filename is changed by one of the handler in the list, then its new value doesn't apply for the remainder of the handlers and only applies when next phase is moved to. This is how it works now for stacked handlers in a single phase. If PythonInterpPerDirective is used however it gets harder as the directory corresponding to the first handler in the list would be used. This however is probably not what you want as the interpreter corresponding to parent would be used and not the lowest level child. What may be more appropriate is that mod_python keep notionally distinct the list of merged handlers and execute each group within its appropriate interpreter based on its own context. This effectively means that for a particular phase it is going to have to call into apache.CallBack().HandlerDispatch() multiple times, acquiring and releasing the interpreters in turn for each call. Could be done, but expected behaviour would need to be well defined first. > Add means of optionally merging handlers from parent context into a child > context. > -- > > Key: MODPYTHON-162 > URL: http://issues.apache.org/jira/browse/MODPYTHON-162 > Project: mod_python > Type: New Feature > Components: core > Reporter: Graham Dumpleton > > Blantently stealing documentation from mod_perl, would be nice to have an > equivalent to the following feature. > MergeHandlers > Turn on merging of Perl*Handler arrays. For example with a setting: > PerlFixupHandler Apache2::FixupA > > > PerlFixupHandler Apache2::FixupB > > a request for /inside only runs Apache2::FixupB (mod_perl 1.0 behavior). But > with this configuration: > PerlFixupHandler Apache2::FixupA > > > PerlOptions +MergeHandlers > PerlFixupHandler Apache2::FixupB > > a request for /inside will run both Apache2::FixupA and Apache2::FixupB > handlers. > Currently mod_python behaves like mod_perl 1.0 in that specifing a handler in > a child context will cause any handler for the same phase in a parent context > to be totally ignored. In mod_perl 2.0, you can use the MergeHandlers option > to say that list of handlers for a parent can be merged with those a of a > parent context. > In mod_perl 2.0 it is an all or nothing affair. Ie., you cant say that you > only want handlers for specific phases merged. It might be worth > investigating whether it could be more flexible. For example: > PythonFixupHandler FixupA > > > PythonMergeHandlers +PythonFixupHandler > PythonFixupHandler FixupB > > > PythonMergeHandlers -PythonFixupHandler > PythonFixupHandler FixupC > > Thus, if /, runs FixupA, if /inside, runs FixupA and FixupB. If > /inside/inside, runs FixupC. Ie., '-' resets back to default of not merging > with parent. -- 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-165) Exporting functions from mod_python to allow access to interpreters etc.
Exporting functions from mod_python to allow access to interpreters etc. Key: MODPYTHON-165 URL: http://issues.apache.org/jira/browse/MODPYTHON-165 Project: mod_python Type: New Feature Components: core Reporter: Graham Dumpleton I have ranted a bit about this before: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01087.html and issue came up again recently on httpd mailing list so thought it was time to note my ideas about it. The idea is that mod_python should export a number of functions using: APR_DECLARE_OPTIONAL_FN macro so that they are available to other Apache modules. These functions would allow access to interpreter instances, the stored Python request object for the current request, as well as functions for creating server, filter and connection Python wrapper objects. The functions and prototypes would be something like the following: PyInterpreterState *mp_acquire_interpreter(const char *name); Get/create the Python interpreter instance called "name". A thread state object would be created as necessary. void mp_release_interpreter(void); Release the currently held thread state object for the interpreter. PyObject *mp_get_request_object(request_rec *req); Get the Python request object wrapper for "req". A new reference is returned which will need to Py_DECREF'd when no longer required. If the request object instance had already been created within mod_python or through an earlier call, it is a reference to the existing instance that is returned. PyObject *mp_create_server_object(server_rec *server); Create a new instance of Python server object wrapper for "server". This is a new reference and will need to be Py_DECREF'd when no longer required. PyObject* mp_create_connection_object(conn_rec *connection); Create a new instance of Python connection object wrapper for "connection". This is a new reference and will need to be Py_DECREF'd when no longer required. PyObject* mp_create_filter_object(ap_filter_t *f, apr_bucket_brigade *bb, int is_input, ap_input_mode_t mode, apr_size_t readbytes); Create a new instance of Python filter object wrapper for filter and bucket brigade. This is a new reference and will need to be Py_DECREF'd when no longer required. It is actually quite simple to create these wrappers around current mod_python internals. What it would effectively allow you to do is to create an Apache module which is written principally in C code and which therefore has access to all features of Apache. Ie., it could define its own directives or even access stuff like mod_dav hooking mechanism. Having used all those mechanisms to set it self up, when it executes it could acquire a Python interpreter instance and make calls out to Python code to perform work. The Python wrapped request/server/connection/filter objects can be supplied to the Python code, as well as any other Python objects the module itself creates which wrap up other parts of Apache, for example, mod_dav structures. The only part of the current mod_python that needs to be changed to support this is that how the interpreter name is stored in the Python request object needs to be changed, specifically it has to be removed. This doesn't mean req.interpreter will not work, when that is accessed it would behind the scenes link back to apache.interpreter for the name of the interpreter the code is executing under and get it from there. -- 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-146) ap_internal_fast_redirect() and request object cache
[ http://issues.apache.org/jira/browse/MODPYTHON-146?page=comments#action_12371714 ] Graham Dumpleton commented on MODPYTHON-146: Correction to previous recipe for explicitly using an internal redirect to get around the problems as described above. The code should only perform the redirect when req.uri already ends with a slash, otherwise it will override Apache's inbuilt mechanism for adding the trailing slash by send a redirect back to the client. Using features now available because of other changes, should say: def fixuphandler(req): if req.finfo[apache.FINFO_FILETYPE] == apache.APR_DIR: if req.uri[-1] == '/': uri = req.uri + 'index.html' if req.args: uri += '?' + req.args req.internal_redirect(uri) return apache.DONE return apache.OK > ap_internal_fast_redirect() and request object cache > > > Key: MODPYTHON-146 > URL: http://issues.apache.org/jira/browse/MODPYTHON-146 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2.8 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > > mod_python uses a Python class to wrap the Apache request_rec structure. The > primary purpose of the request object wrapper is to access the request_rec > internals. One of the other features of the request object wrapper is that > handlers can add their own attributes to it, to facilitate communication of > information between handlers. This communication of information between > handlers works because a handler will lookup to see if a request object has > already been created for the request as a whole before creating a fresh > request object wrapper, and will use the existing one instead. > All in all this generally works okay, however, the DirectoryIndex directive > and the ap_internal_fast_redirect() do cause undesirable behaviour in > specific cases. > Now when a request is made against a directory, this is detected by mod_dir, > which in a LAST hooked handler in the fixup handler phase, will use > ap_internal_fast_redirect() to determine if any of the files mentioned in the > DirectoryIndex directive exist. What this function does is run through all > request phases up to and including the fixup handler phase for the file which > would be matched for the entry in DirectoryIndex. If the status comes back OK > indicating the request could be satisfied, it copies all the information from > the sub request request_rec structure into the parent request_rec structure. > It will then proceed with this information to execute the content handler > phase. > The problem is that ap_internal_fast_redirect() knows only about the > request_rec structure and nothing about the Python request object wrapper. As > a consequence, the request object created for the sub request which worked > and ran through to the fixup handler phase is being ignored and that > originally created for the parent request continues to be used. As a > consequence, any of the attributes added by handler phases up to and > including the fixup handler are lost. > What possibly needs to be done is that the get_request_object() function in > mod_python needs to add to req->notes a tag which identifies the instance of > the request object which has been created. Because req->notes will be > overlayed by the notes table contents from the sub request, it will be able > to detect when this copy of sub request data into the parent has occured. It > can then decide to switch to the request object created for the sub request, > updating the request_rec member to point to the parent request_rec instead. > What may also come out of of storing an id for a request object in the > req->notes table is that when an internal redirect occurs, instead of a fresh > request object wrapper instance being created to use for the req.main > attribute, it can use the id in req->notes to actually get hold of the real > request object of the parent and chain to it properly. Doing this will mean > then that a sub request will be able to access attributes added into a > request object of the parent request, something which can't currently be done. > Now, if you understand everything I have said above, you have done well. ;-) > Depending on whether people do understand or not, when I get a chance I'll > try and attach some examples of handlers which demonstrate he problem. > Acknowledgements that you understand the issue appreciated. -- 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-149) Allow cross subdomain sessions.
Allow cross subdomain sessions.
---
Key: MODPYTHON-149
URL: http://issues.apache.org/jira/browse/MODPYTHON-149
Project: mod_python
Type: Improvement
Components: session
Reporter: Graham Dumpleton
Assigned to: Graham Dumpleton
When session class creates cookie, it does not explicitly set the "domain"
attribute. This means that the session will only apply to the specific site the
request was targeted at. This precludes a single server hosting multiple
virtual host subdomains under a parent domain and a session being shared across
these sites.
The code could perhaps be enhanced to allow an option to be set to force the
inclusion of a "domain" attribute in the cookie for the session much like it
currently allows with the "path" attribute. The option for the latter is
"ApplicationPath". As noted in MODPYTHON-127 there is an intent to properly
namespace these mod_python options so maybe there should be an option:
mod_python.Session.application_domain
with Session code implementing following in make_cookie() method:
if config.has_key("mod_python.Session.application_domain"):
c.domain = config["mod_python.Session.application_domain"]
Setting the domain though would only be required if you want cross site session
cookies within an enclosing domain, it would not be required for a single site.
Depending on whether multiple applications are being hosted on sites under the
same domain, an application may also want to override the session cookie name
and session cookie path to avoid conflicts between multiple applications when
doing this.
--
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] Work started: (MODPYTHON-107) mod_python.publisher shouldn't flush result when written.
[ http://issues.apache.org/jira/browse/MODPYTHON-107?page=all ] Work on MODPYTHON-107 started by Graham Dumpleton > 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.7 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > Fix For: 3.3 > > 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] Assigned: (MODPYTHON-107) mod_python.publisher shouldn't flush result when written.
[ http://issues.apache.org/jira/browse/MODPYTHON-107?page=all ] Graham Dumpleton reassigned MODPYTHON-107: -- Assign To: Graham Dumpleton > 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.7 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > Fix For: 3.3 > > 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] Created: (MODPYTHON-141) Allow handlers to trigger proxying of requests.
Allow handlers to trigger proxying of requests. --- Key: MODPYTHON-141 URL: http://issues.apache.org/jira/browse/MODPYTHON-141 Project: mod_python Type: Improvement Components: core Versions: 3.3 Reporter: Graham Dumpleton Assigned to: Graham Dumpleton Fix For: 3.3 The req.proxyreq and req.uri attributes are not currently modifiable. If they were modifable, it would be possible for a mod_python handler to trigger proxying of a request to some remote site. For example: import posixpath from mod_python import apache def fixuphandler(req): if req.proxyreq: return apache.DECLINED normalised_uri = posixpath.normpath(req.uri) if normalised_uri: if normalised_uri != '/' and req.uri[-1] == '/': normalised_uri += '/' length = len(req.filename) length -= len(req.hlist.directory) - 1 length += len(req.path_info or '') baseurl = normalised_uri[:-length] path = normalised_uri[len(baseurl):] req.proxyreq = apache.PROXYREQ_REVERSE req.uri = 'http://www.dscpl.com.au' + path req.filename = 'proxy:%s' % req.uri req.handler = 'proxy-server' return apache.OK See further discussion on mailing list: http://www.modpython.org/pipermail/mod_python/2006-March/020500.html http://www.modpython.org/pipermail/mod_python/2006-March/020502.html http://www.modpython.org/pipermail/mod_python/2006-March/020503.html http://www.modpython.org/pipermail/mod_python/2006-March/020507.html Patches are include in the last of these emails rather than being attached here. -- 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] Work started: (MODPYTHON-141) Allow handlers to trigger proxying of requests.
[ http://issues.apache.org/jira/browse/MODPYTHON-141?page=all ] Work on MODPYTHON-141 started by Graham Dumpleton > Allow handlers to trigger proxying of requests. > --- > > Key: MODPYTHON-141 > URL: http://issues.apache.org/jira/browse/MODPYTHON-141 > Project: mod_python > Type: Improvement > Components: core > Versions: 3.3 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > Fix For: 3.3 > > The req.proxyreq and req.uri attributes are not currently modifiable. If they > were modifable, it would be possible for a mod_python handler to trigger > proxying of a request to some remote site. For example: > import posixpath > from mod_python import apache > def fixuphandler(req): > if req.proxyreq: > return apache.DECLINED > normalised_uri = posixpath.normpath(req.uri) > if normalised_uri: > if normalised_uri != '/' and req.uri[-1] == '/': > normalised_uri += '/' > length = len(req.filename) > length -= len(req.hlist.directory) - 1 > length += len(req.path_info or '') > baseurl = normalised_uri[:-length] > path = normalised_uri[len(baseurl):] > req.proxyreq = apache.PROXYREQ_REVERSE > req.uri = 'http://www.dscpl.com.au' + path > req.filename = 'proxy:%s' % req.uri > req.handler = 'proxy-server' > return apache.OK > See further discussion on mailing list: > http://www.modpython.org/pipermail/mod_python/2006-March/020500.html > http://www.modpython.org/pipermail/mod_python/2006-March/020502.html > http://www.modpython.org/pipermail/mod_python/2006-March/020503.html > http://www.modpython.org/pipermail/mod_python/2006-March/020507.html > Patches are include in the last of these emails rather than being attached > here. -- 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-109) Signal handler calling Py_Finalize() when child processes being killed.
[ http://issues.apache.org/jira/browse/MODPYTHON-109?page=comments#action_12368628 ] Graham Dumpleton commented on MODPYTHON-109: It will be random as to whether a registered cleanup handler in this situation would be able to run, let alone work. Ignoring the fact that you are doing complicated stuff in a signal handler, which is nearly always bad, the simple fact is that if a normal request handler is in the middle of handling a request and is thus holding the GIL when the parent Apache process decides to send the signal, the cleanup handler will block waiting to acquire the GIL. On UNIX systems at least where a signal handler causes main thread and any other threads to stop for the period the signal handler is run (not sure about Win32 where a signal handler is a distinct thread) , the request handler will never be able to release the GIL so the cleanup handler can't even begin to run. Thus if you are lucky, the cleanup handler will not block and will run, but even then the code is being run from a signal handler which will cause problems in itself and may result in the process crashing. All very dodgy. > Signal handler calling Py_Finalize() when child processes being killed. > --- > > Key: MODPYTHON-109 > URL: http://issues.apache.org/jira/browse/MODPYTHON-109 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > > When Apache is killing off child processes as part of actions taken when the > "apachectl restart" or "apachectl graceful" command is run, it sends a > SIGTERM signal to the child processes. This causes a signal handler > registered by Apache to be run. That signal handler destroys the main child > memory pool. That memory pool has though a cleanup handler associated with it > which was registered by mod_python. That cleanup handler ultimately calls > Py_Finalize(). > The problem with this is that Py_Finalize() isn't safe to be called from a > signal handler and if a handler is still executing or there is a separate > thread running in the context of Python, a deadlock will likely ensue. This > will prevent the child process exiting due to the SIGTERM causing the Apache > parent process to send it a SIGKILL to really kill it. > For a more detailed assessment of the problem and what lead to this > conclusion see: > http://www.modpython.org/pipermail/mod_python/2006-January/019865.html > http://www.modpython.org/pipermail/mod_python/2006-January/019866.html > http://www.modpython.org/pipermail/mod_python/2006-January/019870.html > To avoid the problem, the only choice seems to be avoid calling Py_Finalize() > from the signal handler. The simplistic way of doing this seems to be to add: > if (child_init_pool) > return APR_SUCCESS; > at the start of python_finalize(). This will mean that Py_Finalize() is never > called in child processes. The full consequences of this is unknown, but on > face value it would seem that it might be a reasonable thing to do. More > research may be required. -- 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-132) Expose ap_construct_url() in request object.
[
http://issues.apache.org/jira/browse/MODPYTHON-132?page=comments#action_12368261
]
Graham Dumpleton commented on MODPYTHON-132:
This ap_construct_url() method held so much promise as far as solving the
redirection issue. Unfortunately, it seems to get it wrong occasionally. :-(
req.the_request = GET /~grahamd/authenhandler/?invalidate HTTP/1.1
req.headers_in["host"] = localhost:8080
req.connection.local_addr = ('127.0.0.1', 8080)
For whatever reason though in this one case, it spat out:
http://localhost/~grahamd/authenhandler/login.html
What happened to my port number?
I think it is tied up with fact that request was against a directory and it was
doing odd things based on DirectoryIndex value. Ie., Apache was trying multiple
alternatives and after first somehow decided to not bother including port
properly.
But then, I was trying to use mod_python.util.redirect() in an authenhandler
and it looks like the redirect function may actually be buggy. Specifically,
mod_python.util.redirect() returns apache.OK when it should actually be
returning apache.DONE as it forms a complete response. Because it wasn't
returning apache.DONE, Apache kept trying to match files in DirectoryIndex when
it should have given up after the first because a redirect response was being
returned.
Will have to do some testing and will have to post a distinct issue if it
should be changed.
> Expose ap_construct_url() in request object.
>
>
> Key: MODPYTHON-132
> URL: http://issues.apache.org/jira/browse/MODPYTHON-132
> Project: mod_python
> Type: Improvement
> Components: core
> Versions: 3.3
> Reporter: Graham Dumpleton
>
> Apache provides the function ap_construct_url(). Its purpose is:
> char *ap_construct_url (pool *p, const char *uri, const request_rec *r)
> This function builds a fully qualified URI string from the path specified
> by uri, using the information stored in the request record r to determine
> the server name and port. The port number is not included in the string
> if it is the same as the default port 80.
> For example, imagine that the current request is directed to the virtual
> server www.modperl.com at port 80. Then the following call will return
> the string http://www.modperl.com/ index.html:
> char *url = ap_construct_url(r->pool, "/index.html", r);
> This may be a solution to issue previously discussed about how to create a
> full URL for purpose of doing a redirect.
> Even if not perfect, should be exposed as req.construct_url(). After all, the
> Apache folks are more likely to get this correct and maintain it, better than
> we can do our own version in Python.
--
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-137) Add req.server.get_options() for obtain PythonOption values set at global level.
[ http://issues.apache.org/jira/browse/MODPYTHON-137?page=all ] Graham Dumpleton updated MODPYTHON-137: --- Attachment: grahamd_20060228_MP137_1.diff Attached "grahamd_20060228_MP137_1.diff" containing proposed changes. > Add req.server.get_options() for obtain PythonOption values set at global > level. > > > Key: MODPYTHON-137 > URL: http://issues.apache.org/jira/browse/MODPYTHON-137 > Project: mod_python > Type: New Feature > Components: core > Versions: 3.3 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > Fix For: 3.3 > Attachments: grahamd_20060228_MP137_1.diff > > The req.server.get_config() member seems like it is supposed to allow access > to values of configuration directives set at global context. It seems though > to have a few problems with it though. See MODPYTHON-133 and MODPYTHON-134. > Regardless of that, it seems it may be appropriate to provide an equivalent > for PythonOption directive settings. Specifically req.server.get_options(). > This would return a table object giving all PythonOption value settings > performed at global scope. This would be useful where a value needs to be set > globally in one place and not be overridable in more constrained > configuration containers. > This might for example be used as a way or allowing the mutex directory to be > specified in the Apache configuration as well as as a "configure" command > line option. See MODPYTHON-131. > See commentary along with some patches in: > http://www.mail-archive.com/python-dev@httpd.apache.org/msg01295.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-43) mod_python.publisher auth functions access to globals
[ http://issues.apache.org/jira/browse/MODPYTHON-43?page=all ]
Graham Dumpleton updated MODPYTHON-43:
--
Attachment: grahamd_20060224_MP43_1.diff
Patches attached as grahamd_20060224_MP43_1.diff.
If no one can see problems with this, I will commit change into repository for
3.3.
> mod_python.publisher auth functions access to globals
> -
>
> Key: MODPYTHON-43
> URL: http://issues.apache.org/jira/browse/MODPYTHON-43
> Project: mod_python
> Type: Improvement
> Components: publisher
> Versions: 3.1.4
> Reporter: Graham Dumpleton
> Priority: Minor
> Attachments: grahamd_20060224_MP43_1.diff
>
> In the mod_python.publisher code, the code for performing basic authentication
> has in a few spots code of the form:
> if "__auth__" in func_code.co_names:
> i = list(func_code.co_names).index("__auth__")
> __auth__ = func_code.co_consts[i+1]
> if hasattr(__auth__, "co_name"):
> __auth__ = new.function(__auth__, globals())
> found_auth = 1
> What this does is that if the target of the request is a function and that
> function
> contains a nested function, which in this case is called "__auth__", then that
> nested function is turned into a callable object and is subsequently called to
> determine if the user is able to perform the request.
> In making the nested function callable, it uses "globals()". By using this
> though
> it is using the globals from the mod_python.publisher module and not the
> module which the nested function is contained within. This means that the
> following code will actually fail.
> import xxx
> def function(req):
> def __auth__(req,username,password):
> return xxx.auth(req,username,password)
> This is because the module "xxx" imported at global scope within the module
> isn't
> available to the nested function when it is called as it is seeing the
> globals of
> mod_python.publisher instead. To get around the problem, the import has to be
> local to the nested function.
> def function(req):
> def __auth__(req,username,password):
> import xxx
> return xxx.auth(req,username,password)
> Since in this case the auth function being called is a nested function, we
> know that
> we can actually grab the globals for the correct module by getting
> "func_globals"
> from the enclosing function.
> if "__auth__" in func_code.co_names:
> i = list(func_code.co_names).index("__auth__")
> __auth__ = func_code.co_consts[i+1]
> if hasattr(__auth__, "co_name"):
> __auth__ = new.function(__auth__, object.func_globals)
> found_auth = 1
> Ie., instead of "globals()", use "object.func_globals" where "object is the
> enclosing
> function object.
--
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-125) Improvements associated with req.handler for type checker phase.
[
http://issues.apache.org/jira/browse/MODPYTHON-125?page=comments#action_12367176
]
Graham Dumpleton commented on MODPYTHON-125:
Note that although changes have been commited to make req.handler writable.
Nothing has been done about making req.content_encoding and
req.content_languages writable. Nor has anything been done about the fact that
req.content_languages isn't documented. Seperate issue should possibly be
created for these changes.
> Improvements associated with req.handler for type checker phase.
>
>
> Key: MODPYTHON-125
> URL: http://issues.apache.org/jira/browse/MODPYTHON-125
> Project: mod_python
> Type: Improvement
> Components: core
> Versions: 3.3
> Reporter: Graham Dumpleton
>
> One purpose of the type checker phase in Apache, as able to be hooked using
> the PythonTypeHandler directive, is to use it to make decisions as to which
> actual handler should be used to deliver up the content for a request. It is
> also intended to be used to set up attributes such as req.content_type,
> req.content_encoding and req.content_languages. An example of an Apache
> module which supplies a function for this phase is mod_mime. That module uses
> lookups based on content type as derived from request URL extension type, to
> specify which handler should be used to generate the content. Another is
> mod_negotiation, which performs other sorts of determinations based on the
> request extension.
> In mod_python, there are a few missing bits which would allow you to use
> mod_python to do the same sorts of things. These are that req.handler,
> req.content_encoding and req.content_languages are not writable. Of these the
> most important is probably req.handler.
> To illustrate how it might be used, imagine an Apache configuration for a
> directory of:
> PythonTypeHandler select_handler
> PythonHandler deliver_content
> Although the PythonHandler directive is specified here, it is never actually
> called. This is because the configuration doesn't specify either "SetHandler"
> or "AddHandler" directives. When the SetHandler directive is used, normally
> the Apache core would see it and trigger mod_python for the content handler
> phase. If AddHandler is instead used, it is mod_mime that would trigger
> mod_python be used if the extension matches that in the request URL.
> Instead of using either of these directives, what should instead be able to
> be done is that a handler associated with PythonTypeHandler could say that
> mod_python should be triggered for the content phase. This might be done
> something like:
> def typehandler(req):
> if os.path.splitext(req.filename)[1] == ".py":
> req.handler = "mod_python"
> return apache.OK
> return apache.DECLINED
> You might even say exactly which handler should be called as well.
> def typehandler(req):
> if os.path.splitext(req.filename)[1] == ".py":
> req.handler = "mod_python"
> req.add_handler("PythonHandler","mod_python.publisher")
> return apache.OK
> return apache.DECLINED
> Unfortunately, this doesn't work because req.handler isn't writable. With
> req.handler writable it does work and the handler associated with
> PythonHandler, or as specified using req.add_handler() will be executed for
> the content phase.
> Now the main intent of this JIRA issue is to make req.handler writable, but
> at the same time it is to highlight that for completeness, that
> req.content_encoding and req.content_languages should also probably be made
> writable as they are values which for example are modifed by mod_mime in this
> phase of processing. Note that req.content_type is already writable, which is
> another attribute which mod_mime modifies in this phase.
>
--
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-129) HandlerDispatch doesn't treat OK/DECLINED result properly for all phases.
[ http://issues.apache.org/jira/browse/MODPYTHON-129?page=comments#action_12367169 ] Graham Dumpleton commented on MODPYTHON-129: >From a bit of discussion on mailing list, have come to conclusion that how content handlers are treated should stay the same. For other phases, should be made to work how Apache does things. Final summary post from mailing list below. Okay, I think I have a good plan now. To summarise the whole issue, the way Apache treats multiple handlers in a single phase for non content handler phases is as follows: PostReadRequestHandler RUN_ALL TransHandler RUN_FIRST MapToStorageHandler RUN_FIRST InitHandler RUN_ALL HeaderParserHandler RUN_ALL AccessHandlerRUN_ALL AuthenHandlerRUN_FIRST AuthzHandler RUN_FIRST TypeHandler RUN_FIRST FixupHandler RUN_ALL LogHandler RUN_ALL RUN_ALL means run all handlers until one returns something other than OK or DECLINED. Thus, handler needs to return DONE or an error to have it stop processing for that phase. RUN_FIRST means run all handlers while they return DECLINED. Thus, needs handler to return OK, DONE or error to have it stop processing for that phase. Where multiple handlers are registered within mod_python for a single phase it doesn't behave like either of these. In mod_python it will keep running the handlers only while OK is returned. Returning DECLINED causes it to stop. This existing behaviour can be described (like mod_perl) as stacked handlers. Having non content handler phases behave differently to how Apache does it causes problems. For example things like a string of authentication handlers which only say OK when they handle the authentication type, can't be implemented properly. In Apache, it should stop the first time one returns OK, but in mod_python it will keep running the handlers in that phase. In summary, it needs to behave more like Apache for the non content handler phases. In respect of the content handler phase itself, in practice only one handler module is supposed to implement it. At the Apache level there is no concept of different Apache modules having goes at the content handler phase and returning DECLINED if they don't want to handle it. This is reflected in how in the type handler phase, selection of the module to deliver content is usually done by setting the single valued req.handler string. Although, when using mod_python this is done implicitly by setting the SetHandler/AddHandler directives and mod_negotiation then in turn setting req.handler to be mod_python for you. Because mod_python when executed for the content handler phase is the only thing generating the content, the existing mechanism of stacked handlers and how the status is handled is fine within just the content handler phase. Can thus keep that as is and no chance of stuffing up existing systems. Where another phase calls req.add_handler() to add a handler or multiple handlers for the "PythonHandler" (content) phase, these will be added in a stacked manner within that phase. This also is the same as it works now. There would be non need to have a new function to add stacked handlers as that behaviour would be dictated by phase being "PythonHandler". For all the non content handler phases though, the current stacked handlers algorithm used by mod_python would be replaced with how Apache does it. That is, within multiple handlers registered with mod_python for non content handler phase, it would use RUN_FIRST or RUN_ALL algorithm as appropriate for the phase. For those which use RUN_ALL, this wouldn't be much different than what mod_python does now except that returning DECLINED would cause it to go to next mod_python handler in that phase instead of stopping. It is highly unlikely that this change would have an impact as returning DECLINED in RUN_ALL phases for how mod_python currently implements it, tends not to be useful and can't see that anyone would have been using it. For those which use RUN_FIRST, the difference would be significant as reurning OK will now cause it to stop instead of going to next mod_python handler in the phase. Personally I don't think this would be a drama as not many people would be using these phases and highly unlikely that someone would have listed multiple handlers for such phases. If they had and knew what they were doing, they should have long ago realised that the current behaviour was a bit broken and it even probably stopped them from doing what they wanted unless they fudged it. As to use of req.add_handler() for non content handler phases, each call would create a distinct handler, ie., no stacking of handlers at all. No separate function is required though, as slight change in behaviour determine form phase specified. To sum up, I think these changes would have minimal if no impact as where changes are signific
[jira] Commented: (MODPYTHON-124) Improvements associated with the req.ap_auth_type attribute.
[ http://issues.apache.org/jira/browse/MODPYTHON-124?page=comments#action_12366954 ] Graham Dumpleton commented on MODPYTHON-124: Whoops, stuffed up what the names should be. They should be: req.auth_name() req.auth_type() If "get_" prefix is used, breaks with existing convention as to how names in request object map to Apache API functions. Thus: def authenhandler(req): if req.auth_type() != "Python-Basic-DBM": return apache.DECLINED realm = req.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 > 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 > > 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 lo
[jira] Created: (MODPYTHON-137) Add req.server.get_options() for obtain PythonOption values set at global level.
Add req.server.get_options() for obtain PythonOption values set at global level. Key: MODPYTHON-137 URL: http://issues.apache.org/jira/browse/MODPYTHON-137 Project: mod_python Type: New Feature Components: core Versions: 3.3 Reporter: Graham Dumpleton The req.server.get_config() member seems like it is supposed to allow access to values of configuration directives set at global context. It seems though to have a few problems with it though. See MODPYTHON-133 and MODPYTHON-134. Regardless of that, it seems it may be appropriate to provide an equivalent for PythonOption directive settings. Specifically req.server.get_options(). This would return a table object giving all PythonOption value settings performed at global scope. This would be useful where a value needs to be set globally in one place and not be overridable in more constrained configuration containers. This might for example be used as a way or allowing the mutex directory to be specified in the Apache configuration as well as as a "configure" command line option. See MODPYTHON-131. See commentary along with some patches in: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01295.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] Commented: (MODPYTHON-94) Calling APR optional functions provided by mod_ssl
[ http://issues.apache.org/jira/browse/MODPYTHON-94?page=comments#action_12366945 ] Graham Dumpleton commented on MODPYTHON-94: --- Changes as contained in requestobject.c.patch and modpython4.tex.patch applied to mod_python SVN trunk in revision 378837. Note though that req.ssl_var_lookup() used instead of req.ssl_var() as commented on already and req.is_https() changed to return integer instead of bool. Latter is in part because of lack of bool support in Python 2.2, but also because all other wrappers for Apache functions returning true/false still return an integer. Thus have made it consistent and if we are going to starting using bool type all should perhaps be changed to make them consistent. Finally, change allowed argument type for req.ssl_var_lookup() to string and disallowed passing of None. If None was allowed, the null pointer may cause internal Apache function to crash. No specific test added to test suite, as can't reasonably produce a generic test because of need to have SSL compiled into Apache and possible need to have a client side SSL certificate. I don't know this stuff, but if someone else can come up with a test then great. > Calling APR optional functions provided by mod_ssl > -- > > Key: MODPYTHON-94 > URL: http://issues.apache.org/jira/browse/MODPYTHON-94 > Project: mod_python > Type: New Feature > Components: core > Environment: Apache 2 > Reporter: Deron Meranda > Fix For: 3.3 > Attachments: modpython4.tex.patch, requestobject.c.patch > > mod_python is not able to invoke APR Optional Functions. There are > some cases however where this could be of great benifit. > For example, consider writing an authentication or authorization handler > which needs to determine SSL properties (even if to just answer the > simple question: is the connection SSL encrypted). The normal way of > looking in the subprocess_env for SSL_* variables does not work in those > early handler phases because those variables are not set until the fixup > phase. > The mod_ssl module though does provide both a ssl_is_https() and > ssl_var_lookup() optional functions which can be used in earlier > phases. For example look at how mod_rewrite calls those; using > the APR_DECLARE_OPTIONAL_FN and APR_RETRIEVE_OPTIONAL_FN > macros. > I can see how it might be very hard to support optional functions in > general because of the C type linkage issue, but perhaps a select few > could be coded directly into mod_python. -- 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_12366941
]
Graham Dumpleton commented on MODPYTHON-77:
---
Changes as contained in grahamd_20051105.tar.gz commited to mod_python SVN
trunk at revision 378803.
> 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:
http://www.atlassian.com/software/jira
[jira] Created: (MODPYTHON-133) req.server.get_config() table object populated wrongly.
req.server.get_config() table object populated wrongly.
---
Key: MODPYTHON-133
URL: http://issues.apache.org/jira/browse/MODPYTHON-133
Project: mod_python
Type: Bug
Components: core
Versions: 3.2
Reporter: Graham Dumpleton
Documentation states for req.server.get_config():
req.server.get_config()
Similar to req.get_config(), but returns a config pointed to by
server->module_config Apache config vector.
where req.get_config() documentation states:
req.get_config()
Returns a reference to the table object containing the mod_python
configuration in effect for this request except for Python*Handler and
PythonOption (The latter can be obtained via req.get_options(). The
table has directives as keys, and their values, if any, as values.
The documentation for req.server.get_config() doesn't actually tell you
anything as to what that really means in practice. What would make most sense
is that req.server.get_config() returns the mod_python configuration which is
applicable to the server as a whole. Ie., outside of any configuration
container such as VirtualHost, Directory, Location or Files. Even if one
assumes that that is what it is mean't to do, that isn't what it actually does.
Consider .htaccess file containing:
SetHandler mod_python
PythonHandler handler
PythonDebug On
Where the handler file contains:
from mod_python import apache
def handler(req):
req.content_type = 'text/plain'
req.write('req.get_config()='+str(req.get_config())+'\n')
req.write('req.server.get_config()='+str(req.server.get_config())+'\n')
return apache.OK
Noting that PythonDebug is off by default and when off it isn't put in the
table objects, if a request is made against that directory for any URL except
"/xxx", I would expect that both req.config() and req.server.get_config() would
not hold any reference to PythonDebug. Ie., expect to see:
req.get_config()={}
req.server.get_config()={}
This isn't what you get though. Instead you get:
req.get_config()={}
req.server.get_config()={'PythonDebug': '1'}
The req.get_config() is correct, but not req.server.get_config().
If the "/xxx" is accessed, you don't get what you expect either. Whereas would
expect:
req.get_config()={'PythonDebug': '1'}
req.server.get_config()={}
get instead:
req.get_config()={'PythonDebug': '1'}
req.server.get_config()={'PythonDebug': '1'}
The problem is that when merely processing the Apache configuration, for the
Files directive, it is adding an entry into req.server.get_config() for
PythonDebug.
The code causing this is:
static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
int val) {
const char *rc = python_directive_flag(mconfig, "PythonDebug", val, 0);
if (!rc) {
py_config *conf = ap_get_module_config(cmd->server->module_config,
&python_module);
return python_directive_flag(conf, "PythonDebug", val, 0);
}
return rc;
}
If this code is changed to:
static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
int val) {
const char *rc = python_directive_flag(mconfig, "PythonDebug", val, 0);
if (!cmd->path) {
py_config *conf = ap_get_module_config(cmd->server->module_config,
&python_module);
return python_directive_flag(conf, "PythonDebug", val, 0);
}
return rc;
}
it works in the way that would seem to make sense.
The change here is that the configuration is only added to the server level
config if "cmd->path" is NULL. This will only be the case when the directive is
used outside of any configuration container.
Note that all the directive functions need to change and not just this one.
Ie., search all of mod_python.c and change any instance of "if (!rc)" to "if
(!cmd->path)" for these directive functions.
There is actually another problem with merging of these flags in the config
objects, but will log that as separate problem when confirmed, as exists
independent of this issue.
--
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-123) Provide handler hook point corresponding to ap_hook_map_to_storage().
Provide handler hook point corresponding to ap_hook_map_to_storage(). - Key: MODPYTHON-123 URL: http://issues.apache.org/jira/browse/MODPYTHON-123 Project: mod_python Type: New Feature Components: core Versions: 3.3 Reporter: Graham Dumpleton In between Apache phases: /* [2] filename-to-URI translation */ ap_hook_translate_name(PythonTransHandler, NULL, NULL, APR_HOOK_MIDDLE); /* [3] header parser */ ap_hook_header_parser(PythonHeaderParserHandler, NULL, NULL, APR_HOOK_MIDDLE); There is actually another phase for mapping the file name against actual storage. The core (default) handler in Apache for this phase does various directory/file tree walking through filesystem directories assocated with Directory/File directives, looking at .htaccess files, evaluating whether symlinks can be followed etc. Basically it works out whether a file might exist and whether it is a candidate for use prior to applying later access/authentication phase tests. In some cases you might want to stop all these checks happening, for example, in mod_proxy it stops it as the resources are actually on a different system and it would be a waste of time. Similarly, looks like Tomcat may also override it, possibly mapping the filename to its own concept of a file store. In order to fill out the holes, seems it may be appropriate for mod_python to allow this phase to be replaced. Ie., have: /* [2 1/2] map to storage */ ap_hook_map_to_storage(PythonStorageHandler, NULL, NULL, APR_HOOK_MIDDLE); Other changes in src/mod_python.c would need to be made as appropriate. -- 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-103) Implement req.add_output_filter().
[
http://issues.apache.org/jira/browse/MODPYTHON-103?page=comments#action_12361401
]
Graham Dumpleton commented on MODPYTHON-103:
Correspondingly, it should be possible to add a req.add_input_filter() function
as well. This is because mod_python input filters only get triggered for the
body of the request. This will only occur though when a call is made to
req.read(). As a consequence, a request handler should probably be able to
register input filters as well, provided it does it before the first req.read()
of any request body content.
Worth noting though is that if the request doesn't specify a content length,
calling req.read() will not cause the input filter to be triggered at that
point. The input filter will however be triggered at some point later on (not
sure where), by Apache so that the input filter will detect end of input and
close off the bucket brigade properly.
> Implement req.add_output_filter().
> --
>
> Key: MODPYTHON-103
> URL: http://issues.apache.org/jira/browse/MODPYTHON-103
> Project: mod_python
> Type: New Feature
> Components: core
> Reporter: Graham Dumpleton
> Fix For: 3.3
>
> Add new member function to request object called "add_output_filter()". This
> would be a wrapper around the function "ap_add_output_filter()" and allow
> previously defined filters to be attached to the current request such that
> output can be filtered through them. For example:
> req.add_output_filter("INCLUDES")
> It would probably be necessary for any such call to be done prior to the
> first output being generated from the request handler.
> In addition to this member function, it may be necessary to also provide
> another member function called something like
> "req.add_python_output_filter()". This would be called something like:
> req.add_python_output_filter("module_name::filter_name",path)
> Ie., like "req.add_handler()" but no first argument for phase.
> This method would allow a specific Python filter handler function to be
> specified. This would be equivalent to using the PythonOutputFilter directive
> to first name a mod_python based filter handler function and then adding it
> as an output filter.
> # Main Apache config.
> PythonOutputFilter module_name::filter_name MYFILTER
> # Handler code.
> req.add_output_filter("MYFILTER")
> Note that the PythonOutputFilter directive can only be used in the main
> Apache configuration file, it cannot be used in a .htaccess file. Whether it
> could be made to work in a .htaccess file in some way needs to be
> investigated. In mod_perl their equivlent seems to allow it.
--
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-102) Bus error with connection handler on secondary port.
[
http://issues.apache.org/jira/browse/MODPYTHON-102?page=comments#action_12361291
]
Graham Dumpleton commented on MODPYTHON-102:
See:
http://www.mail-archive.com/python-dev@httpd.apache.org/msg00750.html
for possibly similar issue previously reported on FreeBSD.
Possible connection to this issue, raised in post:
http://www.mail-archive.com/python-dev@httpd.apache.org/msg00933.html
> Bus error with connection handler on secondary port.
>
>
> Key: MODPYTHON-102
> URL: http://issues.apache.org/jira/browse/MODPYTHON-102
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2
> Environment: Mas OS X 10.3 (Panther)
> Reporter: Graham Dumpleton
>
> Logging this one for posterity as hardly likely that anyone would use
> connection handlers with mod_python for anything meaningful.
> Basic problem is that use of connection handler on secondary listener port is
> resulting in a bus error deep in Apache code when it tries to read data from
> the connection. The problem initially only seems to be present on Mac OS X
> 10.3. The problem could not be duplicated on Linux. On Mac OS X the problem
> occurred with both Apache 2.0.51 and 2.0.55 in both prefork and worker MPM
> modes.
> The connection handler code that was being used was:
> from mod_python import apache
> def connectionhandler(conn):
> apache.log_error("connectionhandler")
> try:
> while 1:
> #conn.write(conn.readline())
> conn.write(conn.read())
> except IOError:
> pass
> return apache.OK
> If this is enabled for the default listener port for Apache, ie., simply add
> in main Apache config:
> PythonPath '["/Users/grahamd/Sites/add_handler"]+sys.path'
> PythonConnectionHandler example::connectionhandler
> The connection handler works and is equivalent to mod_echo.
> If however the connection handler is run on a secondary port, a bus error
> occurs when read() or readline() is called by the connection handler. Ie.,
> Listen 8081
> PythonPath '["/Users/grahamd/Sites/add_handler"]+sys.path'
>
> PythonConnectionHandler example::connectionhandler
>
> Output from gdb is below. Note that if the connection handler simply returns
> apache.DECLINED, everything is okay and Apache will serve up pages fine, only
> when doing read of data from connection handler does it decide to crash.
> (gdb) cont
> Continuing.
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> [Switching to process 2342 thread 0xc03]
> 0x0058 in ?? ()
> (gdb) where
> #0 0x0058 in ?? ()
> Cannot access memory at address 0x58
> Cannot access memory at address 0x58
> #1 0x006068f8 in _conn_read (c=0x1933014, mode=AP_MODE_READBYTES, len=0) at
> connobject.c:117
> #2 0x00606b04 in conn_read (self=0x471da0, args=0xf0101140) at
> connobject.c:177
> #3 0x95fa94a8 in PyEval_GetFuncDesc ()
> #4 0x95fa6c64 in PyEval_EvalCode ()
> #5 0x95fa9728 in PyEval_GetFuncDesc ()
> #6 0x95fa9580 in PyEval_GetFuncDesc ()
> #7 0x95fa6c64 in PyEval_EvalCode ()
> #8 0x95fa9728 in PyEval_GetFuncDesc ()
> #9 0x95fa9580 in PyEval_GetFuncDesc ()
> #10 0x95fa6c64 in PyEval_EvalCode ()
> #11 0x95fa7e30 in PyEval_EvalCodeEx ()
> #12 0x95fa97dc in PyEval_GetFuncDesc ()
> #13 0x95fa9580 in PyEval_GetFuncDesc ()
> #14 0x95fa6c64 in PyEval_EvalCode ()
> #15 0x95fa7e30 in PyEval_EvalCodeEx ()
> #16 0x95f5f354 in PyFunction_SetClosure ()
> #17 0x95f4a8d0 in PyObject_Call ()
> #18 0x95f529e8 in PyMethod_New ()
> #19 0x95f4a8d0 in PyObject_Call ()
> #20 0x95f4ab7c in PyObject_CallMethod ()
> #21 0x0060eab0 in python_connection (con=0x192c540) at mod_python.c:1313
> #22 0x0003fce4 in ap_run_process_connection (c=0x192c540) at connection.c:42
> #23 0x0002395c in process_socket (p=0x186e598, sock=0x507f20,
> my_child_num=-267382460,
> my_thread_num=0, bucket_alloc=0x192c540) at worker.c:520
> #24 0x000240bc in worker_thread (thd=0x460e30, dummy=0xf0101140) at
> worker.c:834
> #25 0x9499d990 in _pthread_body ()
> (gdb)
--
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-97) mod_python.publisher iterables and content_type broken
mod_python.publisher iterables and content_type broken
--
Key: MODPYTHON-97
URL: http://issues.apache.org/jira/browse/MODPYTHON-97
Project: mod_python
Type: Bug
Components: publisher
Versions: 3.2
Reporter: Graham Dumpleton
In 3.2, mod_python.publisher was modified so that if it encountered an
interable it would recursively iterate over the items and publish each with the
result being concatenated.
FWIW, I personally didn't like this as I saw it potentially changing the
behaviour of existing code, although perhaps in contrived cases or for test
code only. I saw that this sort of behaviour should have been managed by the
user by explicit use of a wrapper class instead, rather than it being magic.
End of ramble. :-)
Regardless of my concerns, the behaviour that was added is broken.
Specifically, mod_python.publisher is setting the content type based on the
content of the first item returned from the iterable. For example, consider the
following:
index = [
'',
1000 * "X",
'',
]
When published, this is resulting in the content type being set to 'text/plain'
and not 'text/html'. In part this is perhaps caused by the fact that the
content type check is now performed by looking for a trailing '' in the
content whereas previously it would look for a leading ''. This was
changed because all the HTML prologue that can appear before '' would
often throw out this check with the HTML not being automatically being
detected. Thus at the time it was thought that looking for the trailing
'' would be more reliable. It ain't going to help to go back to using a
leading '' check though as the first item may only contain the prologue
and not ''.
These checks are only going to work for iterables if the results of publishing
of each item were added to the end of a list of strings, rather than being
written back immediately using req.write(). Once all that has been returned by
the iterable is obtained, this can all be joined back together and then the
HTML check done.
Joining all the separate items returned from the iterable back together defeats
the purpose of what this feature was about in the first place and may result in
huge in memory objects needing to be created to hold the combined result just
so the HTML check can be done.
The only way to avoid the problem is for the content type to be set explicitly
by the user before the iterable is processed. This is a bit tricky as it is
mod_python.publisher which is automagically doing this. The best you can do is
something like:
class SetContentType:
def __init__(self,content_type):
self.__content_type = content_type
def __call__(self,req):
req.content_type = self.__content_type
return ""
index = [
SetContentType('text/html'),
'',
1000 * "X",
'',
]
Once you start doing this, the user may as well have provided their own
published function in the first place that set the content type and manually
iterated over items and wrote them to req.write(). This could also be managed
by a user specified wrapper class which is how I saw this as preferably being
done in the first place. Ie.,
class PublishIterable:
def __init__(self,value,content_type):
self.__value = value
self.__content_type = content_type
def __call__(self,req):
req.content_type = self.__content_type
for item in self.__value:
req.write(item)
_values = [
'',
1000 * "X",
'',
]
index = PublishIterable(_values,'text/html')
Personally I believe this automagic publishing of iterables should be removed
from mod_python.publisher. You might still provide a special function/wrapper
that works like PublisherIterable but handles recursive structures and callable
objects in the process, but I feel it should be up to the user to make a
conscious effort to use it and mod_python.publisher shouldn't assume that it
should process any iterable in this way automatically.
--
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-37) Add apache.register_cleanup().
[
http://issues.apache.org/jira/browse/MODPYTHON-37?page=comments#action_12317831
]
Graham Dumpleton commented on MODPYTHON-37:
---
Note, attached diff has minor mistake. See following excerpt from mailing
list note this as well as a bit of documentation.
> I need to know what all parameters apache.register_cleanup() is expecting.
Just like you had called req.register_cleanup() except that cleanup
handler is called on server shutdown like req.server.register_cleanup().
register_cleanup(callable[, data])
Registers a cleanup. Argument callable can be any callable object, the
optional argument data can be any object (default is None). At Apache
child process termination, callable will be called with one argument, data.
If errors are encountered during cleanup processing, they should be in
error log.
Note that I have actually made a minor mistake in the code. In apache.py,
the prototype should be:
def register_cleanup(handler,data=None):
_apache.register_cleanup(_interpreter,_server,handler,data)
I used "args=()" which isn't technically correct but only in as much as
I used "()" instead of "None". I was thinking you could supply a tuple of
arguments whereas you can actually only supply a single argument. What I
did wouldn't have stopped it working though.
Anyway, you should be able to do:
def shutdown1():
apache.log_error("shutdown1")
apache.register_cleanup(shutdown1)
def shutdown2(data):
apache.log_error("shutdown2 %r"%data)
apache.register_cleanup(shutdown2,"data")
> Add apache.register_cleanup().
> --
>
> Key: MODPYTHON-37
> URL: http://issues.apache.org/jira/browse/MODPYTHON-37
> Project: mod_python
> Type: New Feature
> Components: core
> Versions: 3.1.4
> Reporter: Graham Dumpleton
> Priority: Minor
> Attachments: register_cleanup.diff.txt
>
> The only way to register cleanup methods to be executed upon child termination
> is through req.server.register_cleanup(). Since the cleanup method isn't
> specific
> to a request, it seems that there should also be an
> apache.register_cleanup(). This
> would allow cleanup function registration upon child termination to be done
> from
> a module imported using the PythonImport directive.
--
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-38) Passing req.form into psp.PSP().
[ http://issues.apache.org/jira/browse/MODPYTHON-38?page=comments#action_65564 ] Graham Dumpleton commented on MODPYTHON-38: --- Have something else to question in the run() code above. That is, I think that doing: if session is not None: session.unlock() is questionable and probably shouldn't be done. It should be done in the cleanup handler registered by the session object itself when it is created if I remember things correctly. Especially if we start caching session object in the req object, by unlocking it, even if it was created by the PSP object, it makes the session object unusable in code that may follow explicit use of PSP object in a handler, or in a subsequent log handler. > Passing req.form into psp.PSP(). > > > Key: MODPYTHON-38 > URL: http://issues.apache.org/jira/browse/MODPYTHON-38 > Project: mod_python > Type: Improvement > Versions: 3.1.4 > Reporter: Graham Dumpleton > Priority: Minor > > When calling psp.PSP() explicitly to render PSP pages, it will internally > setup > req.form if it determines that the form is accessed by the PSP page. > Problem is that if you are wanting to trigger psp.PSP() from a publisher > function > any form parameters have already been processed and req.form created. For a > POST request this is problematic as in doing this it will have consumed all > the > content of the request. > This means that when the form is processed a second time by psp.PSP(), it will > find no request content. Thus, the PSP page will only be able to make use of > GET form parameters and not POST form parameters. > It would be an improvement if psp.PSP() allowed a instance of > util.FieldStorage > which has previously been created to be passed in through the "form" parameter > of the constructor. Ie., > template = psp.PSP(req,filename=path,vars=settings,form=req.form) > template.run() -- 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
