Re: [jira] Created: (MODPYTHON-183) Stop Python directives being used in .htaccess files.
I like this proposal. The PythonAllowOverride -whatever in particular is something that has great appeal. Jim Graham Dumpleton (JIRA) wrote: 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: Directory /home/*/public_html AddHandler mod_python .py PythonHandler mod_python.publisher PythonInterpPerDirective On PythonDebug on /Directory 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.
Graham: Suggested change to importer.py
I had some modules with circular imports and I only discovered that this was a problem when I tried to discover why my modules were being reimported constantly. I would suggest that this code be changed to log an error that explicitly tells you that there's a circular import, and what the consequences are. # Check for a child which refers to one of its # ancestors. Hopefully this will never occur. If # it does we will force a reload every time to # highlight there is a problem. if label in ancestors: # LOG HELPFUL ERROR HERE return True Also, I still chafe every time I have to write: sidewinder_dir = r'C:\Docume~1\Dan\MyDocu~1\PYROOT\sidewinder\\' from mod_python import apache session = apache.import_module(sidewinder_dir+'session.py') config = apache.import_module(sidewinder_dir+'config.py') Instead of: import session import config My handler imports modules like so: IMPORT_PATH = [config.server_options['sidewinder_dir'], config.web['root']] apache.import_module(mpath, path=IMPORT_PATH) Which works great, but when those modules import something I have to use the ugly mess above. Maybe you and I could think of a better way? I'd like if I could just add an option globally to my httpd.conf like: PythonOption ChildrenAlwaysInheritImportPath On Or maybe add another parameter to import_module like: apache.import_module(mpath, path=IMPORT_PATH, inherit=True) Or? Thanks, -Dan
[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: Directory /home/*/public_html AddHandler mod_python .py PythonHandler mod_python.publisher PythonInterpPerDirective On PythonDebug on /Directory 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] 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] 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-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-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-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-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/ Directory d:/python24/B2B AddHandler mod_python .py PythonHandler pyHandlerHTTP PythonDebug On /Directory = Test handler - pyHandlerHTTP.py : = import mod_python from mod_python import util def handler(req): #Removing this line solves the problem. F=util.FieldStorage( req ) return mod_python.apache.OK = HTTP Request (dump using TCPWATCH): = POST http://localhost:80/python/Alertes.py HTTP/1.0 Content-Type: multipart/form-data; boundary=061006144341906 Content-Length: 209 Proxy-Connection: keep-alive Host: www.tx2-localhost Accept: text/html, */* User-Agent: Mozilla/3.0 (compatible; Indy Library) Proxy-Authorization: Basic Og== --061006144341906 Content-Disposition: form-data; name=TYPE LAST_ALERTS --061006144341906 Content-Disposition: form-data; name=FILEAGE 180 --061006144341906 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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-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] 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] 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] 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-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 Assuming these are accessed as: /~grahamd/mod_python_9/subdir-1/index.py
[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
Re: [Vote] product name - for shipping versions
Well I'm on vacation so thats why I don't reply much. But i do agree that it does more than just just HTTP. this will be even more true if mod_ftp gets out of incubator. So I'm not really for the HTTP in de name. On 8/10/06, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Thu, Aug 10, 2006 at 12:26:23PM -0700, William A. Rowe, Jr. wrote: Pretty darned quiet - either it's summer or nobody feels like joining the fray when Roy and Will go at it? Well, Paul's talk in San Diego got me thinking. We're not really just about HTTP any more, it's a misnomer. We're about delivering information using many different protocols accross the internet. I don't know, something like Internet Information Server just seems more appropriate somehow. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED] -- ~Jorge
Re: Product name - for future versions
I still stand by Apache Server Framework as the best choice. I like this a lot too! (Or either Apache World Dominitation Project j/k) -- ~Jorge
Re: [PATCH 40026] ServerTokens Off
Sorry for joining the discussion so lately. This issue was raised several times in this list. It was voted off in all of them, because of several reasons, one of them was not mentioned this time: Apache's strongest marketing point has been always its dominance among the web servers. With about 70% in all of the market researches, from netcraft.co.uk to securityspace.com, Apache became the first option for almost everybody. It's sure that the Off option will hurt the statistics of Apache. Many of us will love to see this option going away, because everybody can do it very easily through the source code, as Yahoo! and others already did. But if this option is a so strong dream for somebody, the minimum that can be done to help a little, is a strong recommendation against using this option, in the documentation. My English is not great, so I leave the exact words for somebody else, but this recommendation should say that using the Off option is not social, pays bad for the great efforts that Apache's developers put into this project, and should be used only in closed networks or if there is no other choice. Something like use it only if you know what you are doing. After all, people don't pay anything for the great efforts of the Apache's developers, and crediting Apache is the only nominal thank that they can do. Of course, the statistics of Apache is going to suffer even with this warning, but without it - it is going to be even worse. I also think that adding this option requires a new license (2.1?) stating that You must mention Apache in this HTTP header, so technically it will be possible to use Off, but not according to the license. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH 40026] ServerTokens Off
On 8/12/06, Eli Marmor [EMAIL PROTECTED] wrote: But if this option is a so strong dream for somebody, the minimum that can be done to help a little, is a strong recommendation against using this option, in the documentation. I'm +1 on the concept for this patch (I haven't reviewed the code). I think that the docs should say something like noteSetting directiveServerTokens/directive to less than codeminimal/code is not recommended because it makes it more difficult to debug interoperational problems./note And my +1 isn't very strong. I have no problem with saying that this small bit of advertising is the tiny price that you pay for using our free software. But just to make this never-ending issue go away, I'd say put it in. Joshua.
Re: [PATCH 40026] ServerTokens Off
Joshua Slive wrote: noteSetting directiveServerTokens/directive to less than codeminimal/code is not recommended because it makes it more difficult to debug interoperational problems./note And my +1 isn't very strong. I have no problem with saying that this small bit of advertising is the tiny price that you pay for using our free software. But just to make this never-ending issue go away, I'd say put it in. I should also be pointed out in the documentation that those thinking of setting it to Off for the purpose of security by obscurity (for hiding of implementation and version number) should realize that this concept has no technical merit in the HTTP server situation. Call this an education clause in the documentation which may head off inappropriate usage by less clueful users. With regards to the price that you pay ... I take it that you are reading it from the karma equalization policy not in any legal policy since one of the fundamental points of the Apache Foundation is that advertisement is not one of the prices you pay. Darryl
