Re: Constructing of a URL for location redirect.
Nicolas Lehuen wrote: BTW, did we ever considered using SWIG to map the Apache API ? I know it can be quite tricky to use, but it could be a real time saver. That's essentially what mod_snake did, and why I liked it so much. Though I don't remember if it used swig or pyrex. Nick
Re: Constructing of a URL for location redirect.
Gregory (Grisha) Trubetskoy wrote: SWIG in my opinion is good when you want some kind of an API made available to you quickly, but in a static environment where can put some thought into functionality, usability, Pythonic-ness of every approach, write documentation with good examples and a meaningful test case SWIG does not buy much. If someone just wanted to map the APR to Python - they can always use SWIG, but that's not what mod_python is about. All true; mod_python is a layer up from the apache API, so there's no way the SWIGed API could come close to replacing it. I just found it generally more convenient to work in Python rather than C, even if it's only a thin layer above that, and I think there is some merit to using it in some places, carefully wrapped in a Python class or module. That said, I don't really see mod_python changing so radically at this point in the game. It's fun to think about, though. :) In a masochistic kind of way. Nick
[jira] Created: (MODPYTHON-131) Make name of mutex directory configurable.
Make name of mutex directory configurable. -- Key: MODPYTHON-131 URL: http://issues.apache.org/jira/browse/MODPYTHON-131 Project: mod_python Type: Improvement Components: core Versions: 3.2 Reporter: Graham Dumpleton 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
Python 2.x; what's x?
Graham Dumpleton (JIRA) writes: If mod_python is to still support Python 2.2, which it looks like we are still because of Nokia work, then can't use the Python bool type yet as that was only added to Python 2.3. But can't a decision be made? I think deciding by not deciding is less than an ideal design process. It sure would be nice to have a decisive: We support python versions 2.x and greater. So, what's x? Seems like a core developer vote, but my 2-cents is I'm hoping it's 3, for the same reasons I outlined in a previous thread: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01127.html Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: Python 2.x; what's x?
Daniel J. Popowich wrote .. Graham Dumpleton (JIRA) writes: If mod_python is to still support Python 2.2, which it looks like we are still because of Nokia work, then can't use the Python bool type yet as that was only added to Python 2.3. But can't a decision be made? I think deciding by not deciding is less than an ideal design process. It sure would be nice to have a decisive: We support python versions 2.x and greater. So, what's x? Seems like a core developer vote, but my 2-cents is I'm hoping it's 3, for the same reasons I outlined in a previous thread: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01127.html Version 3.2.7 was made to be able to work with Python 2.2. http://www.mail-archive.com/python-dev@httpd.apache.org/msg01123.html Your right though. I'm not sure if a final policy was stated that 2.2 and later would be supported, there was a sort of consensus, but no actual official statement unless I missed it. FWIW, the last production system I have to deal with that has Python 2.2 will be upgraded to Python 2.3 in the next month, so on that point it makes no difference to me. At the moment, I don't think we loose anything by still supporting 2.2. That is, there is nothing specific in 2.3 which would be of huge benefit. Thus, no harm still supporting 2.2 at least for mod_python 3.2.X stream. We may well want to reconsider that for mod_python 3.3 stream. The particular patch I was talking about is going to go into 3.2.X stream, so should still work for Python 2.2. Thus, let us at least state that mod_python 3.2.X will retain support for Python 2.2. As to the mod_python 3.3 stream, there would be no gaurantees that Python 2.2 will be supported. Yes I realise this is deferring the decision again, but at the moment we don't know how long before 3.3 is done. If it takes a while, as it probably will, then by then, saying that Python 2.3 only is supported will probably be a quite reasonable thing to do. Graham
[jira] Created: (MODPYTHON-134) Setting PythonDebug to Off, doesn't override On setting in parent scope.
Setting PythonDebug to Off, doesn't override On setting in parent scope.
Key: MODPYTHON-134
URL: http://issues.apache.org/jira/browse/MODPYTHON-134
Project: mod_python
Type: Bug
Components: core
Versions: 3.2
Reporter: Graham Dumpleton
If you put:
PythonDebug On
in your main Apache configuration file, one would assume that you can then in a
.htaccess file say:
PythonDebug Off
and that in the .htaccess file would override that in the main Apache
configuration for any requests landing in the directory the .htaccess file is
for. That is, that PythonDebug would be Off.
You might assume this, but it doesn't work.
Similarly, even within a .htaccess file, if you have:
PythonDebug On
Files xxx
PythonDebug Off
/Files
one would assume that accessing /xxx in that directory would see PythonDebug
being Off.
That doesn't work either.
The problem comes about from the fact that each container context has a
separate table object. All these table objects are merged together, with values
in more specific containers pertaining to a request, overriding those from a
parent container. Unfortunately, in mod_python 3.X (wasn't the case in 2.7),
the python_directive_flag() function was added and coded to not put an entry in
the table object for the Off case.
The current code for the python_directive_flag() function is:
static const char *python_directive_flag(void * mconfig,
char *key, int val, int set)
{
py_config *conf;
conf = (py_config *) mconfig;
if (val) {
apr_table_set(conf-directives, key, 1);
}
else {
if (set) {
apr_table_set(conf-directives, key, 0);
}
else {
apr_table_unset(conf-directives, key);
}
}
return NULL;
}
Note that the line section:
if (set) {
apr_table_set(conf-directives, key, 0);
}
was only added back in mod_python 3.2.7 specifically to fix problem with
PythonAutoReload not working as documented in MODPYTHON-106. Back in mod_python
2.7, setting the value to 0 is what always occured, it didn't use to use
unset:
apr_table_unset(conf-directives, key);
Since the unset instead of adding in 0 was used, there was no table object
value for Off and so it can't override On in a parent container and so it still
inherits the On value. Thus why it can't be turned Off once On.
Seems the only solution is to go back to using:
static const char *python_directive_flag(void * mconfig,
char *key, int val)
{
py_config *conf;
conf = (py_config *) mconfig;
if (val) {
apr_table_set(conf-directives, key, 1);
}
else {
apr_table_set(conf-directives, key, 0);
}
return NULL;
}
But to do this, other parts of mod_python.c are going to have to be changed.
Specifically MODPYTHON-106 identified:
One can't just always set it to 0, as other code in mod_python.c uses the
fact
that an option exists to mean it is set. Ie., it doesn't check the value,
thus setting
it to 0 will cause that code to think the option used in that case
(PythonInterpPerDirectory,
PythonInterpPerDirective) is set to on when it isn't, thus causing that to
stop working
correctly.
Thus code associated with PythonInterpPerDirectory and PythonInterpPerDirective
is going to have to be changed to check the value in the table object and see
if it is 1. There seems no other choice now.
Note that any user code which also merely checks for the existing of the
directive, such as PythonDebug, without testing the value would also need to be
changed as it will potentially not work properly.
--
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-135) [SECURITY] A Security Issue with FileSession in 3.2.7
[SECURITY] A Security Issue with FileSession in 3.2.7 - Key: MODPYTHON-135 URL: http://issues.apache.org/jira/browse/MODPYTHON-135 Project: mod_python Type: Bug Components: session Versions: 3.2 Reporter: Graham Dumpleton As announced on the mailing list: http://www.modpython.org/pipermail/mod_python/2006-February/020284.html If you are using the recently released mod_python 3.2.7 please beware that a security issue was discovered in the FileSession code. You are vulnerable only if you are using mod_python 3.2.7 AND you are using FileSession to keep sessions. FileSession is new in 3.2.7 and is not enabled by default, therefore if you are using mod_python Session in its default configuration you are not vulnerable. The extent of this vulnerability is limited. Only a user who already has an account (or some ability to write to the filesystem) on the system running httpd could exploit it, and to the best of our knowledge such a user could potentially cause httpd to execute arbitrary code. We are working on a security release of the next version of mod_python and expect it to be out shortly. Until then, please do not use FileSession. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
perl-framework, Makefile.PL with -apxs gives error.
Hi, I have come across this issue when i try to define the apxs argument to point to an httpd installed in used defined location. Here are the steps i have done. and it provided the error output given below. Can any of u help me to get rid of it/ any work around to this. Note: t/TEST -apxs... also gives the same error. 1. svn checkout http://svn.apache.org/repos/asf/httpd/test/trunk/ httpd-test 2. perl Makefile.PL -apxs /home/sris/projects/ers-3-0-2/apache2.0/bin/apxs 3. make 4. t/TEST OUTPUT [EMAIL PROTECTED]:~/projects/temp/httpd-test/perl-framework$ t/TEST [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/sris/projects/temp/httpd-test/perl-framework/t/TEST Use of uninitialized value in concatenation (.) or string at /home/sris/projects/temp/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm line 407. Thanks Regards Sris
docs error
In the trunk docs the link to 'Access Control' in auth.html is broken as access.html seems to not exist in that version. Given the large number of changes maybe it would be a good doc bring to life again?
Re: perl-framework, Makefile.PL with -apxs gives error.
2. perl Makefile.PL -apxs /home/sris/projects/ers-3-0-2/apache2.0/bin/apxs 3. make 4. t/TEST OUTPUT [EMAIL PROTECTED]:~/projects/temp/httpd-test/perl-framework$ t/TEST [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/sris/projects/temp/httpd-test/perl-framework/t/TEST Use of uninitialized value in concatenation (.) or string at /home/sris/projects/temp/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm line 407. well the error is a symptom of something gone awry higher up, notably the inability of Apache-Test to find httpd. if you specify -apxs then essentially $ path/to/apxs -q bindir needs to point to the directory that contains the httpd binary. if it doesn't, or you have a really wacky configuration, just use -httpd instead and you should be ok. HTH --Geoff
how does this get changed?
Rather than try and piece it together, can someone simply answer this simple question? Maybe then this mail and your reply will help other poor souls trying to make the change. Convert this Order deny,allow Deny from all into [ your answer here ]
Re: how does this get changed?
On 2/16/06, David Reid [EMAIL PROTECTED] wrote: Rather than try and piece it together, can someone simply answer this simple question? Maybe then this mail and your reply will help other poor souls trying to make the change. Convert this Order deny,allow Deny from all Require all denied But David, you should really just be including mod_access_compat. I think there are plenty of people here who are going to vote against any release of 2.4 unless configurations like the one above work out of the box with mod_access_compat included. So if you are having problems, it is better to identify them now. Joshua.
Re: mutex dir?
tisdagen den 14 februari 2006 13.17 skrev Oden Eriksson: Hello. [...] I am no programmer, but can't you just look at how this is handled in the core mod_ssl and ldap code? -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: how does this get changed?
Joshua Slive wrote: On 2/16/06, David Reid [EMAIL PROTECTED] wrote: Rather than try and piece it together, can someone simply answer this simple question? Maybe then this mail and your reply will help other poor souls trying to make the change. Convert this Order deny,allow Deny from all Require all denied But David, you should really just be including mod_access_compat. I think there are plenty of people here who are going to vote against any release of 2.4 unless configurations like the one above work out of the box with mod_access_compat included. So if you are having problems, it is better to identify them now. I have been using the compat module (which actually worked this time) but I've run into a SIGBUS or SIGILL (latter if not debug build) using the module. Also, unless there is an upgrade path that make sense, is well documented and tested the new auth stuff might as well never have been added. The last set of auth changes left a bad taste in a lot of peoples mouths - shall we try and avoid that this time round? david
Re: mod_proxy buffering small chunks
* Alan Gutierrez [EMAIL PROTECTED] [2006-02-13 15:48]: * Plüm, Rüdiger, VIS [EMAIL PROTECTED] [2006-02-06 09:29]: -Ursprüngliche Nachricht- Von: Alan Gutierrez The proposed solution is to poll for chunks using non-blocking I/O. When the socket returns EAGAIN, the 8K buffer is flushed, and the socket is read with blocking I/O. Thats the way the code is already designed in 2.2.x. I am aware of this, acutally. I should have noted this myself. I've traced through the code to see where the EAGAIN return value is lost, and to note that the non-blocking mode is not applied to the header. I've not tested, but I suspect that the logic is correctly implemented should the socket block during the transfer of the body of a chunk. It fails when the next chunk has not been sent. However, in the http code, regardless of the block mode flag, the headers are read using blocking I/O. Furthermore, somewhere deeper in the chain, when EAGAIN is detected the success flag is returned instead. I'll provide more detail, if this is not already well known. This is the problem. The EAGAIN or better the mode handling in this code path is somewhat broken. Looks that way. The EAGAIN is never sent back out, and in addition the headers are read with a blocking read. It would require changing the return values of code path, which may way cause some breakage. Maybe not, if EAGAIN is handled correctly in all places, but it's never been tested, since it's never returned, right? Looks like this is going to be messy to fix. Any patches? Not so far. I guess it requires some general changes that must be carefully designed. But anyway, patch proposals are welcome :-). Can I suggest a flag? Something like ProxyChunkedAsIs On What does anyone think? -- Alan Gutierrez - 504 717 1428 - [EMAIL PROTECTED] - http://blogometer.com/
Re: how does this get changed?
maybe if mod_access_compat is included by default statically into httpd itself? (unless explicitly disabled) we could make it optional in 2.6 (and remove docs on it), and remove in 2.8 or something. this will give people plenty of time to switch over. David Reid wrote: Joshua Slive wrote: On 2/16/06, David Reid [EMAIL PROTECTED] wrote: Rather than try and piece it together, can someone simply answer this simple question? Maybe then this mail and your reply will help other poor souls trying to make the change. Convert this Order deny,allow Deny from all Require all denied But David, you should really just be including mod_access_compat. I think there are plenty of people here who are going to vote against any release of 2.4 unless configurations like the one above work out of the box with mod_access_compat included. So if you are having problems, it is better to identify them now. I have been using the compat module (which actually worked this time) but I've run into a SIGBUS or SIGILL (latter if not debug build) using the module. Also, unless there is an upgrade path that make sense, is well documented and tested the new auth stuff might as well never have been added. The last set of auth changes left a bad taste in a lot of peoples mouths - shall we try and avoid that this time round? david
Re: how does this get changed?
Ian Holsman wrote: maybe if mod_access_compat is included by default statically into httpd itself? (unless explicitly disabled) we could make it optional in 2.6 (and remove docs on it), and remove in 2.8 or something. this will give people plenty of time to switch over. This definitely makes sense, +1. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: how does this get changed?
On 2/16/06, Graham Leggett [EMAIL PROTECTED] wrote: Ian Holsman wrote: maybe if mod_access_compat is included by default statically into httpd itself? (unless explicitly disabled) we could make it optional in 2.6 (and remove docs on it), and remove in 2.8 or something. this will give people plenty of time to switch over. This definitely makes sense, +1. Uhh... Please don't remove docs on something that is still in the server. And it should be removed at 3.0. We shouldn't be breaking config files in minor releases. Joshua.
Re: how does this get changed?
Uhh... Please don't remove docs on something that is still in the server. And it should be removed at 3.0. We shouldn't be breaking config files in minor releases. Already happened between 2.0 and 2.2, when mod_access was changed to mod_authz_host. Joost
Re: Constructing of a URL for location redirect.
Nick wrote: Gregory (Grisha) Trubetskoy wrote: SWIG in my opinion is good when you want some kind of an API made available to you quickly, but in a static environment where can put some thought into functionality, usability, Pythonic-ness of every approach, write documentation with good examples and a meaningful test case SWIG does not buy much. If someone just wanted to map the APR to Python - they can always use SWIG, but that's not what mod_python is about. All true; mod_python is a layer up from the apache API, so there's no way the SWIGed API could come close to replacing it. I just found it generally more convenient to work in Python rather than C, even if it's only a thin layer above that, and I think there is some merit to using it in some places, carefully wrapped in a Python class or module. That said, I don't really see mod_python changing so radically at this point in the game. It's fun to think about, though. :) In a masochistic kind of way. We could always try to convince the ASF to rewrite apache in PyPy. :) Jim
auth in trunk is fubar
Had some problems getting a working auth config to let me spend time developing on svn's authz module - when I tried 2.2 the exact same config worked without a problem first time out of the box. Houston, I think trunk's auth code is fubar. Config is as follows, Location /repos DAV svn SVNParentPath /home/david/repos AuthzSVNAccessFile /usr/local/apache2/conf/svn_access AuthType Basic AuthName Subversion repository AuthUserFile /usr/local/apache2/conf/svn_users Satisfy any LimitExcept GET OPTIONS PROPFIND REPORT Require valid-user /LimitExcept /Location Simple GET requests result in a password dialog! with a higher level of output I see that the initial GET request is returned as OK, but it moves onto asking for a password anyways. david
Re: auth in trunk is fubar
* David Reid [EMAIL PROTECTED] [2006-02-17 01:01:51]: Had some problems getting a working auth config to let me spend time developing on svn's authz module - when I tried 2.2 the exact same config worked without a problem first time out of the box. Houston, I think trunk's auth code is fubar. If you don't use mod_access_compat, Svn can't work with Apache trunk because it makes a call to ap_satisfies() -in the auth code of Subversion. This call should be changed to something similar in the new Apache auth mechanism, but my knowledge is too limited to find a remplacement call. If you use mod_acess_compat, sorry, no clue. - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
[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
Files xxx
PythonDebug On
/Files
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
Re: perl-framework, Makefile.PL with -apxs gives error.
Hi Thanks, -httpd works fine. The httpd binary has been built in a custom name like httpsd.worker in my machine. That is the reason y apxs does not locate the httpd binary. Sorry about it. it works after i renamed it to httpd. Regards Sris On Thu, 2006-02-16 at 08:47 -0500, Geoffrey Young wrote: 2. perl Makefile.PL -apxs /home/sris/projects/ers-3-0-2/apache2.0/bin/apxs 3. make 4. t/TEST OUTPUT [EMAIL PROTECTED]:~/projects/temp/httpd-test/perl-framework$ t/TEST [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/sris/projects/temp/httpd-test/perl-framework/t/TEST Use of uninitialized value in concatenation (.) or string at /home/sris/projects/temp/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm line 407. well the error is a symptom of something gone awry higher up, notably the inability of Apache-Test to find httpd. if you specify -apxs then essentially $ path/to/apxs -q bindir needs to point to the directory that contains the httpd binary. if it doesn't, or you have a really wacky configuration, just use -httpd instead and you should be ok. HTH --Geoff
