Re: repeatable SystemError: bad argument to internal function
On 07/10/2007, Aaron Swartz <[EMAIL PROTECTED]> wrote: > re: http://www.modpython.org/pipermail/mod_python/2007-June/023854.html > > I've found a way to make this happen repeatedly. Occurs in both 2.4.2 > and 2.5.1. I have a file where every time I read it in, I get it. If it isn't too large, could you attach the file to: http://issues.apache.org/jira/browse/MODPYTHON-234 Only problem I can see though is that so far this seems to relate more to what size reads are occurring and so suspect that on a different OS or machine setup it may not trigger the same problem for someone else. You might at least therefore gives some details on machine setup but also if possible details of what is happening on client/server side for the request which is causing it so test harness can be produced to try and trigger the same situation. Maybe even just discuss it on mod_python developers list first where I have cc'd this mail. Thanks. Graham
Re: Debian bug#433038: mod_python collides with mod_php5
On 31/08/2007, Robert Edmonds <[EMAIL PROTECTED]> wrote: > Graham Dumpleton wrote: > > In 411487 it mentions: > > > > """So, it seems it's directly related to libmhash2 (as [2] suggests).""" > > > > Disabling of mhash module may not be enough if one of the other PHP > > modules they list in 433038 also use libmhash2 library. Quite possible > > that one of the crypto libraries use it, or the ldap module mentioned > > in the mod_python mailing list mail. > > > > Can you run ldd on main PHP module and all PHP modules and see which > > one has a dependency on libmhash2, or any other md5 hash library. > > In the user's last message to the bug report, he includes the contents > of /proc/.../maps for functioning and malfunctioning apache instances. > > > Basic problem as we understand it is that libmhash2 uses a symbol name > > which clashes with one used by Python md5 module. Which ever gets > > loaded first, usually PHP version, takes precedence and since that is > > not compatible with other package a crash occurs. > > > > If it can be determined that it is libmhash2 and then which symbol in > > it clashes with one in Python md5 module, one or the other could > > somehow be namespace escaped to avoid the problem. > > Is it possibly some other library than libmhash2? The only additonal > cryptography-related DSOs I see present in the user's php instance are: > > /usr/lib/libmcrypt.so.4.4.7 > /usr/lib/php5/20060613+lfs/mcrypt.so > > All the symbols in those DSOs appear to be namespace escaped. Hmmm, it is worrying that there are so many different crypto libraries linked in. /lib/i686/cmov/libcrypt-2.6.1.so /usr/lib/i686/cmov/libcrypto.so.0.9.8 /usr/lib/libgcrypt.so.11.2.3 /usr/lib/libk5crypto.so.3.1 /usr/lib/libmcrypt.so.4.4.7 /usr/lib/php5/20060613+lfs/mcrypt.so Other areas which also have given problems with PHP/mod_python are shared libraries for expat, MySQL, SSL and sqllite. See later sections in: http://code.google.com/p/modwsgi/wiki/ApplicationIssues This is for mod_wsgi, but same things can occur with it. The only way they may possibly work out which is the problem is to attach a debugger to Apache in single process mode and work out where it crashes. Instructions on doing this in later sections of: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques Graham
Re: Debian bug#433038: mod_python collides with mod_php5
In 411487 it mentions: """So, it seems it's directly related to libmhash2 (as [2] suggests).""" Disabling of mhash module may not be enough if one of the other PHP modules they list in 433038 also use libmhash2 library. Quite possible that one of the crypto libraries use it, or the ldap module mentioned in the mod_python mailing list mail. Can you run ldd on main PHP module and all PHP modules and see which one has a dependency on libmhash2, or any other md5 hash library. Basic problem as we understand it is that libmhash2 uses a symbol name which clashes with one used by Python md5 module. Which ever gets loaded first, usually PHP version, takes precedence and since that is not compatible with other package a crash occurs. If it can be determined that it is libmhash2 and then which symbol in it clashes with one in Python md5 module, one or the other could somehow be namespace escaped to avoid the problem. Graham On 31/08/2007, Robert Edmonds <[EMAIL PROTECTED]> wrote: > Hi, > > I'm one of the Debian maintainers of the libapache2-mod-python package. > Could someone please take a look at the report filed here? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433038 > > The user writes, > > If libapache2-mod-python is installed together with libapache2-mod-php5, > (at least) the mod_python.psp handler fails immediately without any proper > error message. > > This also happens if the php5 mhash module is uninstalled, purged and > apache is restarted. mod_python starts working immediately if mod-php5 is > disabled using "a2dismod php5" and restarting apache. > > [...] > > This effectively renders mod_python.psp unusuable as soon as mod-php5 > (maybe together with some specific modules) is installed and it's also > hard > to debug as there's no indication whatsoever of what is going wrong, other > than that it "doesn't work". > > More details are on the page. I'm afraid I'm having difficulties > tracking down the root cause of the user's problem. > > -- > Robert Edmonds > [EMAIL PROTECTED] > >
[jira] Created: (MODPYTHON-241) Incremental memory use when performing streaming over long period.
Incremental memory use when performing streaming over long period. -- Key: MODPYTHON-241 URL: https://issues.apache.org/jira/browse/MODPYTHON-241 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.3.1, 3.2.10 Reporter: Graham Dumpleton Priority: Minor As first raised in: http://www.modpython.org/pipermail/mod_python/2007-July/023964.html when streaming data from mod_python handler over a long period of time, memory use will keep increasing. Note that this isn't actually a memory leak though, as the memory gets reclaimed at the end of the request. The underlying problem arises from mod_python using the ap_rwrite() function to write output data. When this function is used it will create a bucket chain for each block of data written, with the bucket chain coming from the request memory pool. There is no attempt to reuse the bucket chain for successive writes, so memory will increase on every call. The normal solution to this problem is to retain the bucket chain and use it from one call to the next. In mod_python though this isn't simple to achieve because calls to response data may or may not be flushed at the discretion of the user code. The retaining of the bucket chain and using it from one call to the next generally can only be done when data is always being flushed. A more complicated system would be needed which can cope with a need to buffer data at times and yet flush at other times. One approach may be to not actually use Apache itself to buffer data between flushes, but to use Python data structures instead to accumulate references to Python string objects in a Python list so objects are still valid. When flushed only then construct a chain of buckets which use direct reference to raw data of Python string objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-240) LimitRequestBody directive doesn't work well with mod_python handlers.
LimitRequestBody directive doesn't work well with mod_python handlers.
--
Key: MODPYTHON-240
URL: https://issues.apache.org/jira/browse/MODPYTHON-240
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.3.1, 3.2.10
Reporter: Graham Dumpleton
The problem is that mod_python doesn't check whether LimitRequestBody would be
triggered before actually calling the mod_python handler. Thus, that the post
data exceeds the limit is only found when req.read() of mod_python request
object is called and a Python exception is generated because of an unknown read
error.
Now, because a read error of some sort is generated, mod_python handlers would
normally see it as an unexpected exception and it would propagate back and
result in a 500 Internal Server Error page rather than a 413 error back to the
client. Thus a ErrorDocument handler for 413 errors would never be triggered.
FWIW, in mod_wsgi the following is done before the WSGI application is even
triggered.
/*
* Setup policy to apply if request contains a body. Note
* that it is not possible to have chunked transfer encoding
* for the request content. This is actually a limitation in
* WSGI specification as it has no way of indicating that
* there is content of unknown length, nor a way to deal
* with trailers appearing after any chunked content.
*/
status = ap_setup_client_block(r, REQUEST_CHUNKED_ERROR);
if (status != OK)
return status;
/*
* Check to see if request content is too large and end
* request here. We do this as otherwise it will not be done
* until first time input data is read in application.
* Problem is that underlying HTTP output filter will
* also generate a 413 response and the error raised from
* the application will be appended to that. The call to
* ap_discard_request_body() is hopefully enough to trigger
* sending of the 413 response by the HTTP filter.
*/
limit = ap_get_limit_req_body(r);
if (limit && limit < r->remaining) {
ap_discard_request_body(r);
return OK;
}
Do note though that the size check can only be done after
ap_setup_client_block() is called. At the moment this is done first time
req.read() is called. If that is to remain there, then req.read() would need to
do the equivalent of:
raise apache.SERVER_RETURN, apache.HTTP_REQUEST_ENTITY_TOO_LARGE
Problem is that by doing this in req.read() an application may still catch it
and treat it like an unexpected exception and raise a 500 error response
instead.
It is for this reason that mod_wsgi does the check even before the application
is called. If a custom error page is required then ErrorDocument directive
would be used to redirect to a handler.
If an application itself wants to check POST content size, it simply shouldn't
be using LimitRequestBody directive.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-234) SystemError: bad argument to internal function
[ https://issues.apache.org/jira/browse/MODPYTHON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516213 ] Graham Dumpleton commented on MODPYTHON-234: This error also seen by someone using Django and LimitRequestBody directive. http://groups.google.com/group/django-users/browse_frm/thread/fb72bd122ae283ad/fa18c0f8a294f5d1#fa18c0f8a294f5d1 This directive may perhaps be a way of reproducing the problem allowing it to be tracked down. Do note though that as a separate issue, mod_python doesn't work properly with LimitRequestBody. This is described in that discussion but I haven't logged it as a separate issue yet. > SystemError: bad argument to internal function > -- > > Key: MODPYTHON-234 > URL: https://issues.apache.org/jira/browse/MODPYTHON-234 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.10, 3.3.1 >Reporter: Graham Dumpleton > > As raised in thread: > http://www.modpython.org/pipermail/mod_python/2007-June/023795.html > when req.read() is called, on rare occasions it can generate the error: > 05 18:33:49 2007] [error] [client 200.155.85.225] SystemError: > Objects/stringobject.c:3515: bad argument to internal function, > It is speculated that this is caused by an invalid value being supplied to > _PyString_Resize() with code associated with req.read(). In particular, most > likely being supplied a negative value for size. > This issues possibly relates to problems with how mod_python makes use of > content length and what request_rec says in respect of remaining amount of > data as described in MODPYTHON-212. > Further highlights how the code for req.read(), req.readline() and > req.readlines() has to be completely revised and overhauled to simply read > whatever is available rather than trusting content length. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-238) req.connection.keepalive should be writable
[
https://issues.apache.org/jira/browse/MODPYTHON-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511033
]
Graham Dumpleton commented on MODPYTHON-238:
Setting req.chunked to 0 by itself doesn't actually disable chunking. It is all
because of some weird code in modules/http/http_protocol.c which gets called on
first call to write() and which starts with:
if ((r->connection->keepalive != AP_CONN_CLOSE)
&& ((r->status == HTTP_NOT_MODIFIED)
|| (r->status == HTTP_NO_CONTENT)
|| r->header_only
|| apr_table_get(r->headers_out, "Content-Length")
|| ap_find_last_token(r->pool,
apr_table_get(r->headers_out,
"Transfer-Encoding"),
"chunked")
|| ((r->proto_num >= HTTP_VERSION(1,1))
&& (r->chunked = 1))) /* THIS CODE IS CORRECT, see above. */
&& r->server->keep_alive
&& (r->server->keep_alive_timeout > 0)
&& ((r->server->keep_alive_max == 0)
|| (r->server->keep_alive_max > r->connection->keepalives))
&& !ap_status_drops_connection(r->status)
&& !wimpy
&& !ap_find_token(r->pool, conn, "close")
&& (!apr_table_get(r->subprocess_env, "nokeepalive")
|| apr_table_get(r->headers_in, "Via"))
&& ((ka_sent = ap_find_token(r->pool, conn, "keep-alive"))
|| (r->proto_num >= HTTP_VERSION(1,1 {
Thus, if r->connection->keepalive is not AP_CONN_CLOSE, it will overwrite
r->chunked as a side affect of the if condition.
Thus, only way to turn off chunking is to set connection to close as well as
turn chunking to off. Ie.,
r->connection->keepalive = apache.AP_CONN_CLOSE
r->chunked = 0
If you don't care whether chunking is used or not and just want to ensure
connection is closed, would instead use:
r->connection->keepalive = apache.AP_CONN_CLOSE
or (I think):
r->subprocess_env['keepalive'] = "0"
or:
r->headers_out['Connection'] = 'Close'
All up, all I am doing is making writable things at C API level that module
writer may want to change. How they are used is governed by Apache and not
changing that. Frankly, some of this stuff is real black magic. :-(
> req.connection.keepalive should be writable
> ---
>
> Key: MODPYTHON-238
> URL: https://issues.apache.org/jira/browse/MODPYTHON-238
> Project: mod_python
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.3.1
>Reporter: Graham Dumpleton
>Priority: Minor
>
> The attribute req.connection.keepalive should be writable. This would allow
> handlers to use:
> req.connection.keepalive = apache.AP_CONN_CLOSE
> Doing this before any data is written has the effect of disabling keepalive
> and also turning off chunked encoding for response content when no content
> length has been supplied.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-238) req.connection.keepalive should be writable
[ https://issues.apache.org/jira/browse/MODPYTHON-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510973 ] Graham Dumpleton commented on MODPYTHON-238: Actually also need to make req.chunked writable. As it has to be set to 0 in combination with setting close for keepalive to disabled chunked encoding for response. > req.connection.keepalive should be writable > --- > > Key: MODPYTHON-238 > URL: https://issues.apache.org/jira/browse/MODPYTHON-238 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.3.1 >Reporter: Graham Dumpleton >Priority: Minor > > The attribute req.connection.keepalive should be writable. This would allow > handlers to use: > req.connection.keepalive = apache.AP_CONN_CLOSE > Doing this before any data is written has the effect of disabling keepalive > and also turning off chunked encoding for response content when no content > length has been supplied. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-238) req.connection.keepalive should be writable
req.connection.keepalive should be writable --- Key: MODPYTHON-238 URL: https://issues.apache.org/jira/browse/MODPYTHON-238 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton Priority: Minor The attribute req.connection.keepalive should be writable. This would allow handlers to use: req.connection.keepalive = apache.AP_CONN_CLOSE Doing this before any data is written has the effect of disabling keepalive and also turning off chunked encoding for response content when no content length has been supplied. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-237) Publisher doesn't process nested callable objects returned from a top level callable object properly.
Publisher doesn't process nested callable objects returned from a top level callable object properly. - Key: MODPYTHON-237 URL: https://issues.apache.org/jira/browse/MODPYTHON-237 Project: mod_python Issue Type: Bug Components: publisher Affects Versions: 3.3.1, 3.2.10 Reporter: Graham Dumpleton As discussed in thread: http://www.modpython.org/pipermail/mod_python/2007-June/023910.html the publish_object() function in mod_python.publisher, tries to invoke callable objects returned from a callable object. This doesn't always work as the rule set in place and applied on at the top level to restrict what types of objects can be accessed isn't applied. Need to work out whether it should even been recursive calling callable objects, or only provided string representation of any thing returned by the top level callable object. FWIW, publisher in Vampire always only returns a string representation of object returned by top level callable. The code also has other problems if one were to allow returned callable to be recursive called, as doesn't make use of req.form properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-236) Implement official way of getting PSP output as a string.
Implement official way of getting PSP output as a string. - Key: MODPYTHON-236 URL: https://issues.apache.org/jira/browse/MODPYTHON-236 Project: mod_python Issue Type: New Feature Components: psp Reporter: Graham Dumpleton Priority: Minor Given that requests occasionally come in that request or would require the ability to get a string representation of a PSP page, rather than output being sent as response, should add new feature for doing this. This would eliminate the need to use fake request wrappers to capture PSP page output. Such a hack has been described in: http://www.modpython.org/pipermail/mod_python/2005-May/018230.html but would be better if the code generated by the psp_parser.c file would instead of generating req.write() operate via a proxy variable, eg. __output__.write(), where '__output__' would be 'req' for the normal case but could be replaced by the user through an argument to PSP object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-235) Memory leaks in main Apache process when doing 'restart' or 'graceful'.
Memory leaks in main Apache process when doing 'restart' or 'graceful'.
---
Key: MODPYTHON-235
URL: https://issues.apache.org/jira/browse/MODPYTHON-235
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Graham Dumpleton
As raised in thread:
http://www.modpython.org/pipermail/mod_python/2007-June/023926.html
it looks like mod_python exhibits memory leaks in the main Apache process when
a 'restart' or 'graceful' is done. Ie., when only child process are killed off
and restarted rather than whole Apache being stopped.
The poster though seems to be of opinion that it only happens when certain auth
modules are loaded, which makes the behaviour somewhat odd if true. One would
expect it simply to always leak rather than being dependent on the other
modules existing.
As it stands, the whole mod_python initialisation really needs to be done over
because of issues such as MODPYTHON-195. If done it may resolve this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-234) SystemError: bad argument to internal function
SystemError: bad argument to internal function -- Key: MODPYTHON-234 URL: https://issues.apache.org/jira/browse/MODPYTHON-234 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.3.1, 3.2.10 Reporter: Graham Dumpleton As raised in thread: http://www.modpython.org/pipermail/mod_python/2007-June/023795.html when req.read() is called, on rare occasions it can generate the error: 05 18:33:49 2007] [error] [client 200.155.85.225] SystemError: Objects/stringobject.c:3515: bad argument to internal function, It is speculated that this is caused by an invalid value being supplied to _PyString_Resize() with code associated with req.read(). In particular, most likely being supplied a negative value for size. This issues possibly relates to problems with how mod_python makes use of content length and what request_rec says in respect of remaining amount of data as described in MODPYTHON-212. Further highlights how the code for req.read(), req.readline() and req.readlines() has to be completely revised and overhauled to simply read whatever is available rather than trusting content length. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-233) Race condition in req.sendfile().
Race condition in req.sendfile(). - Key: MODPYTHON-233 URL: https://issues.apache.org/jira/browse/MODPYTHON-233 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton Priority: Minor In code for req.sendfile() if no length is supplied indicating how much data should be sent then a stat() is performed on the file to determine the amount of data in the file. The file is then opened and that much data sent. Technically this would be a problem if the file changed in between the stat() and sending the data. The result could be that not all data in the file is sent. To possibly avoid this problem, but also may improve efficiency of sending files, it would probably be better if an APR file bucket be created and added to the output bucket chain rather than mod_python itself reading data from the file and write it back in the response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-232) PHP mhash module causes problems with Python md5 module.
PHP mhash module causes problems with Python md5 module. Key: MODPYTHON-232 URL: https://issues.apache.org/jira/browse/MODPYTHON-232 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton Priority: Minor The Python md5 module is used in Session/Cookie code and also in the new module importer of mod_python 3.3.1. For some PHP installations where PHP mhash module is being loaded, there is some sort of conflict between the two md5 hash libraries. This can result in mod_python code which relies on md5 module to not work properly. To avoid this problem, suggest that Apache APR md5 routines being exposed through the _apache module and mod_python use that whereever md5 hashes required. This way operation of mod_python at least will not be comprised, although it will not help with higher level application such as Django which access md5 module themselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-231) PythonInterpPer* may yield incorrect results on case insensitive file systems.
PythonInterpPer* may yield incorrect results on case insensitive file systems. -- Key: MODPYTHON-231 URL: https://issues.apache.org/jira/browse/MODPYTHON-231 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton When matching a URL to an actual physical directory on a file system, for a case insensitive file system various combinations of upper and lower case characters in URL may match to the same actual directory. If using the PythonInterpPerDirective or PythonInterpPerDirectory directives this may result in multiple Python sub interpreter instances being created instead of one for a particular target context. This is because the name of the Python sub interpreter uses the file system path which may contain the user modifiable mixture of upper and lower case letters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-230) Module importer doesn't deal with case insensitive file systems properly.
Module importer doesn't deal with case insensitive file systems properly. - Key: MODPYTHON-230 URL: https://issues.apache.org/jira/browse/MODPYTHON-230 Project: mod_python Issue Type: Bug Components: importer Affects Versions: 3.3.1 Reporter: Graham Dumpleton As highlighted in: http://www.modpython.org/pipermail/mod_python/2007-May/023603.html the module importer in mod_python 3.3.1 doesn't cope properly with case insensitive file systems such as on Windows and MacOS X platforms. Problem is that part of a URL may be used in constructing the actual path of a Python code file to be loaded by the module importer. As such, the user can dictate what the case of characters used in the physical file path may be. On a case sensitive file system this is not a problem because if the file doesn't exist with that case an error would occur. On a system with a case insensitive file system however, various combinations of characters in a URL, upper or lower case, may match a physical file. The actual problem now is that the module importer will take the path exactly as given and use it to construct a dummy module name and further uses that to index into the module cache. With different combinations of upper and lower case, the end result will be that there could be multiple versions of the same module loaded into the process. This could cause problems where the module has global data that is updated and consulted from one request to the next. On Windows and MacOS X systems, the _module_label() function should lower case the path name before generating the module name key. An option should be provided however to override this behaviour on Windows and MacOS X in the event that a case sensitive file system is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-229) Revise what is returned by util.Field.__str__.
Revise what is returned by util.Field.__str__. -- Key: MODPYTHON-229 URL: https://issues.apache.org/jira/browse/MODPYTHON-229 Project: mod_python Issue Type: Task Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton Priority: Minor As pointed out in: http://www.modpython.org/pipermail/mod_python/2007-May/023683.html http://www.modpython.org/pipermail/mod_python/2007-May/023684.html http://www.modpython.org/pipermail/mod_python/2007-May/023685.html the __str__() method of util.Field() in mod_python 3.3.1 does not return a value which could be eval'd in order to get back some meaningful object. In mod_python 3.2.10 it work. The change which stops it working was that to make util.Field() accept more than two arguments. This code should perhaps be revised at some point as to whether it could be changed to something more useful. That file callbacks are now supported may make it problematic. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-228) Awk command line options behaviour on Solaris 10 changes.
Awk command line options behaviour on Solaris 10 changes.
-
Key: MODPYTHON-228
URL: https://issues.apache.org/jira/browse/MODPYTHON-228
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Graham Dumpleton
Priority: Minor
Configure script uses:
AC_MSG_CHECKING(flex version)
FlexVERSION=`$LEX --version | sed 's/version//g' | awk '/flex/ {print $2}'`
Flex_MAJOR=`echo $FlexVERSION| awk -F . '{print $1}'`
Flex_MINOR=`echo $FlexVERSION| awk -F . '{print $2}'`
Flex_PATCH=`echo $FlexVERSION| awk -F . '{print $3}'`
Problem is that on Solaris 10 the awk program was changed so as not to accept a
space after the -F option.
Ie., on Solaris 9 the manual page says:
/usr/bin/awk [-f progfile] [-F c] [ ' prog '] [parameters] [filename...]
But on Solaris 10 it says:
/usr/bin/awk [-f progfile] [-Fc] [ ' prog '] [parameters] [filename...]
This means that if flex version check performed on Solaris 10 the awk command
will fail.
checking flex version... awk: syntax error near line 1
awk: bailing out near line 1
awk: syntax error near line 1
awk: bailing out near line 1
awk: syntax error near line 1
awk: bailing out near line 1
./configure: line 3187: test: : integer expression expected
For further details see:
http://www.modpython.org/pipermail/mod_python/2007-March/023230.html
Configure script should perhaps search for presence of 'gawk', 'nawk' and 'awk'
in that order. That way it will give preference to BSD awk variants rather than
SYSV variant which can be different in other respects as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-225) Allow Python executable location and Python home to be specified.
[ https://issues.apache.org/jira/browse/MODPYTHON-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509002 ] Graham Dumpleton commented on MODPYTHON-225: When doing this, changes should be made to testhandler to display the various settings, eg sys.executable, in some way. > Allow Python executable location and Python home to be specified. > - > > Key: MODPYTHON-225 > URL: https://issues.apache.org/jira/browse/MODPYTHON-225 > Project: mod_python > Issue Type: New Feature > Components: core >Affects Versions: 3.3.1 >Reporter: Graham Dumpleton > > Where a user has multiple versions of Python installed getting mod_python to > work can be problematic. > The main issue is where a version of Python is installed in a location > different to where the standard operating system version is installed. For > example, if /usr/bin/python is Python version 2.4 and a user has installed > Python version 2.5 as /usr/local/bin/python. And the user has compiled > mod_python against Python 2.5 and not the operating system version 2.4. > Under normal circumstances Apache is only going to look in /usr/bin when > started from an init.d script and not in /usr/local/bin. The result of this > is that Python when initialised will find /usr/bin/python and assume that > that is the base it should use to start with to find where the Python library > files are installed. In doing this though it will not be able to find > /usr/lib/python2.5 as what it really needs to be able to find is > /usr/local/lib/python2.5. The final outcome will be that mod_python will not > be able to find the Python code files for itself when starting up. > The only way around this is to set the PATH environment variable in the > startup scripts for Apache to look in /usr/local/bin before /usr/bin. > Alternatively, on some UNIX platforms (but not necessarily all) it is > possible to set the environment variable PYTHONEXECUTABLE to be the exact > location of the python executable specified when configuring mod_python. > Finally, on UNIX platforms one can also set PYTHONHOME to be the exact > location of either a shared platform independent/dependent Python library > directory, or where separate directories a colon separated list of the two > directories. In the latter Python will skip the whole search process and > simply use the two values. > Having to use environment variables to do this can be a pain as it may be > necessary to modify init.d startup scripts to make it work. What should > really be done is that mod_python should provide for UNIX platforms the > directives PythonExecutable and PythonHome as equivalents to using the > PYTHONEXECUTABLE and PYTHONHOME environment variables. These values if > defined can be used in calls to Py_SetProgramName() and Py_SetPythonHome() > appropriately. > This will allow the Apache configuration file itself to be used to qualify > which version of Python should be used when non standard versions not in the > standard locations are being used. > Note that these directives shouldn't be required on the Windows platform as > it uses the Windows registry to find where the Python library files are > located. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-222) Support for chunked transfer encoding on request content.
[ https://issues.apache.org/jira/browse/MODPYTHON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507735 ] Graham Dumpleton commented on MODPYTHON-222: Do note that changing the API to allow it will not help if the client doesn't used chunked encoding for request content. My understanding is that browsers may not have a way of saying it should be used and generally it requires a programming language level HTTP client, such as urllib2 or similar to be able to make use of it. > Support for chunked transfer encoding on request content. > - > > Key: MODPYTHON-222 > URL: https://issues.apache.org/jira/browse/MODPYTHON-222 > Project: mod_python > Issue Type: New Feature > Components: core >Affects Versions: 3.3.1 > Reporter: Graham Dumpleton > > It is currently not possible to use chunked transfer encoding on request > content delivered to a mod_python request handler. > The use of chunked transfer encoding is explicitly blocked in C code by: > rc = ap_setup_client_block(self->request_rec, REQUEST_CHUNKED_ERROR); > To allow chunked transfer encoding instead of REQUEST_CHUNKED_ERROR it would > be necessary to supply REQUEST_CHUNKED_DECHUNK. > Problem is that it isn't that simple. > First off, the problems associated with MODPYTHON-212 have to be fixed with > code being able to cope with there being no content length. > The next issue is that req.read() method is currently documented as behaving > as: > If the len argument is negative or omitted, reads all data given by the > client. > This means that can't have req.read() with no arguments mean give me > everything that is currently available in input buffers as everyone currently > expects it to return everything sent by client. Thus, to be able to process > streaming data one would have to supply an amount of data that one wants to > read. The code for that though will always try to ensure that that exact > amount of data is read and will block if not enough and not end of input. A > handler though may not want it to block and be happy with just getting what > is read and only expect it to block if nothing currently available. > In other words, the current specification for how req.read() behaves is > incompatible with what would be required to support chunked transfer encoding > on request content. > Not sure how this conflict can be resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MODPYTHON-220) In PSP pages, 'import' doesn't map through to apache.import_module().
[
https://issues.apache.org/jira/browse/MODPYTHON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton updated MODPYTHON-220:
---
Attachment: MP220-20070622-1-grahamd.diff
Attached patch MP220-20070622-1-grahamd.diff which fixes this problem.
> In PSP pages, 'import' doesn't map through to apache.import_module().
> -
>
> Key: MODPYTHON-220
> URL: https://issues.apache.org/jira/browse/MODPYTHON-220
> Project: mod_python
> Issue Type: Improvement
> Components: psp
>Affects Versions: 3.3.1
>Reporter: Graham Dumpleton
> Attachments: MP220-20070622-1-grahamd.diff
>
>
> When Python code appears in SSI files, a trick is performed such that the
> Python code in the SSI files is seen as having been originally imported using
> the new module importer. This means that if 'import' is used with the Python
> code, it will map through to apache.import_module() and first use that
> mechanism to try and import code modules. This trick is not performed for PSP
> pages however.
> What needs to be done for PSP pages is the equivalent of the SSI trick:
> class _InstanceInfo:
> def __init__(self, label, file, cache):
> self.label = label
> self.file = file
> self.cache = cache
> self.children = {}
> filter.req.ssi_globals["__file__"] = filter.req.filename
> filter.req.ssi_globals["__mp_info__"] = _InstanceInfo(
> None, filter.req.filename, None)
> filter.req.ssi_globals["__mp_path__"] = []
> What this is doing is setting up in the environment of the SSI code object
> the magic variables that 'import' hook looks for to allow it to map to
> apache.import_module().
> If same done in PSP pages then 'import' will map to apache.import_module()
> for PSP pages also as first step.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-220) In PSP pages, 'import' doesn't map through to apache.import_module().
[
https://issues.apache.org/jira/browse/MODPYTHON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506331
]
Graham Dumpleton commented on MODPYTHON-220:
Workaround is that instead of using:
import module
use:
from mod_python import apache
module = apache.import_module("module")
> In PSP pages, 'import' doesn't map through to apache.import_module().
> -
>
> Key: MODPYTHON-220
> URL: https://issues.apache.org/jira/browse/MODPYTHON-220
> Project: mod_python
> Issue Type: Improvement
> Components: psp
>Affects Versions: 3.3.1
>Reporter: Graham Dumpleton
>
> When Python code appears in SSI files, a trick is performed such that the
> Python code in the SSI files is seen as having been originally imported using
> the new module importer. This means that if 'import' is used with the Python
> code, it will map through to apache.import_module() and first use that
> mechanism to try and import code modules. This trick is not performed for PSP
> pages however.
> What needs to be done for PSP pages is the equivalent of the SSI trick:
> class _InstanceInfo:
> def __init__(self, label, file, cache):
> self.label = label
> self.file = file
> self.cache = cache
> self.children = {}
> filter.req.ssi_globals["__file__"] = filter.req.filename
> filter.req.ssi_globals["__mp_info__"] = _InstanceInfo(
> None, filter.req.filename, None)
> filter.req.ssi_globals["__mp_path__"] = []
> What this is doing is setting up in the environment of the SSI code object
> the magic variables that 'import' hook looks for to allow it to map to
> apache.import_module().
> If same done in PSP pages then 'import' will map to apache.import_module()
> for PSP pages also as first step.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-169) Add feature to allow mod_python to be an auth provider.
[
https://issues.apache.org/jira/browse/MODPYTHON-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503347
]
Graham Dumpleton commented on MODPYTHON-169:
The _path change is not valid.
The real problem is that the proposed patches to the Python code parts of
mod_python don't appear to have been originally written for mod_python 3.3 and
therefore don't take into consideration all the changes made to the module
importer in mod_python 3.3. Some of the other code in there is also not up to
date with how things are done in mod_python 3.3.
I haven't really looked at the code in detail, but the presence of a few things
in there makes me want to question whether the way it is hooked into mod_python
is necessarily the best way of doing all this. So, by all means experiment with
this, but don't necessarily expect it to end up being implemented like this if
ever added in.
> Add feature to allow mod_python to be an auth provider.
> ---
>
> Key: MODPYTHON-169
> URL: https://issues.apache.org/jira/browse/MODPYTHON-169
> Project: mod_python
> Issue Type: New Feature
> Components: core
>Reporter: Graham Dumpleton
>Assignee: Graham Dumpleton
> Attachments: add-authenticator.patch
>
>
> 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 a
Re: TLP Name
To confirm my vote in correct format: +1 Quetzalcoatl Graham On 22/05/07, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]> wrote: On Sun, 20 May 2007, Justin Erenkrantz wrote: > FWIW, the full name of the TLP will be: "Apache " - so "Apache > PyPache" doesn't roll off the tongue very well... Yes, Apache PyPache does sound a bit silly. My vote is then: +1 Quetzalcoatl Those who have not voted yet (there are hundreds of you, I know) PLEASE keep on sending in your votes. Grisha
Re: sys.path and htaccess change?
On 18/05/07, Daniel J. Popowich <[EMAIL PROTECTED]> wrote: Graham Dumpleton writes: > And that is what the documentation I pointed you at states: > > """Note that with the new module importer, as directories associated > with Python*Handler directives are no longer being added automatically > to sys.path and they are instead used directly by the module importer > only when required, some existing code which expected to be able to > import modules in the handler root directory from a module in a > subdirectory may no longer work. In these situations it will be > necessary to set the mod_python module importer path to include '~' or > list '~' in the __mp_path__ attribute of the module performing the > import.""" OK, I think it's slowly sinking in...when I put the ~ in, it didn't affect sys.path, so my import still wasn't going to work. Right? Correct, you were only changing the path related to modules managed by the new module importer and not those handled by the standard Python importer. Adding "~" like that would also only have been needed if in a subdirectory of the handler root directory an import was trying to be done with either 'import' or 'apache.import_module()' for a module in the handler root directory. I had assumed in suggesting that, that you had already converted mpservlets to use the new module importer and were triggering that specific case. So, how the heck do I import the modules? In just about all cases exactly how you do it now. Although, where you were using your own module importing and caching system for working under mod_python, you would need to adapt it to use the new importer. Do I have to use apache.import_module() now? No. In fact there are now cases where before you had to use apache.import_module() because of bugs but you now can use just 'import' and it will also work, thus allowing one to create sets of modules that can also be used safely outside of mod_python in a test framework. That you have an existing module importing and caching system of your own is a special case but only the module importer code in moservlets should need to change, not anything else. But I don't want to! As far as using it in mpservlets itself, that would be a pity really as one of the main reasons that support for importing files by full path with an arbitrary extension was added was so that mpservlets could make use of the new importer rather than use its own, and thus benefit from some of the features the new module importer provided such as root modules being imported automatically when a child was changed thereby avoiding the need to restart Apache after anything but simple changes. Thus, in the tutorial example, I could adjust _SitePage and thereby notionally change the appearance of the whole site without a restart, something that couldn't be avoided with how mpservlets worked with previous versions of mod_python. > If one wants to be precise, the addition of the handler directory to > sys.path was actually done by the top level mod_python dispatch code > rather than the module importer itself. And this I don't understand at all. If this "feature" was in the old system, why would reimplementing an api function change this behaviour in the dispatch code? I would consider this a bug. That it did add the handler directory to sys.path previously is what caused a lot of the bugs documented in the page I referred to in the first place. There was no choice but to change it else you couldn't fix the existing bugs. You may have avoided the bugs by using your own module importer, but the bugs still affected everyone else. The whole point of the changes which were made was to draw a well defined line between the code modules used in the web application and which reside in the document tree, or other specially specified areas by way of mod_python module importer path, and the standard Python sys.path locations. That there was no distinction before is what caused all the issues with same named modules, loading of incorrect modules, reloading of modules which shouldn't be reloaded etc etc. I would also say this is WAY too much functionality change for a minor release update. I did suggest that the release be called 4.0, but since there was a backwards compatibility switch so people could reenable old behaviour for module importer while they update their code the consensus was that 3.3 was okay. Also, the whole thing was intended to be as compatible as possible. In the end there was only a few cases where people would actually have to make changes, the main one being where people were relying on handler root direct being in sys.path so imports from non mod_python managed modules could find a module in that directory. > The other important bit is: > > """As a
Re: sys.path and htaccess change?
On 18/05/07, Daniel J. Popowich <[EMAIL PROTECTED]> wrote: Graham Dumpleton writes: > > When I go to http://localhost/~dpopowich/py/syspath, a simple > > mpservlet that writes out the current value of sys.path, I do NOT see > > /home/dpopowich/public_html/py in the path. > > You will not see the path listed in sys.path. The mod_python module > importer path and the Python sys.path are deliberately kept separate > because of all the problems caused by each looking in the same > location. But I did see the path in sys.path before 3.3. Prior to 3.3, the directory that contained the SetHandler directive would be in sys.path. I have no idea if this behaviour in versions <3.3 is because of the old apache.import_module or some other "feature," but it's not there in 3.3. And that is what the documentation I pointed you at states: """Note that with the new module importer, as directories associated with Python*Handler directives are no longer being added automatically to sys.path and they are instead used directly by the module importer only when required, some existing code which expected to be able to import modules in the handler root directory from a module in a subdirectory may no longer work. In these situations it will be necessary to set the mod_python module importer path to include '~' or list '~' in the __mp_path__ attribute of the module performing the import.""" This was immediately below the example line I referred you to go look for. If one wants to be precise, the addition of the handler directory to sys.path was actually done by the top level mod_python dispatch code rather than the module importer itself. The other important bit is: """As a new feature in mod_python 3.3, when using the standard Python 'import' statement to import a module, if the import is being done from a module which was previously imported by the mod_python module importer, it is equivalent to having called apache.import_module() directly.""" It is because of this that the directory doesn't need to be in sys.path, as under the covers, when 'import' is being used by modules imported by the mod_python module importer directly in some way, then 'import' is equivalent to having used 'apache.import_module()' and therefore it looks in places related to mod_python including stuff in the separate mod_python importer path. > > And when I try to import > > a python module in that directory, I get import errors. > > If you are still using the old module importer in mpservlets to import > your .mps file then that would probably still occur. No. I do NOT use apache.import_module() to load .mps files. I rolled my own, using execfile on the filename coming from req.filename. When I said 'old module importer' in that case, I meant your hand rolled one in mpservlets, not the old mod_python one. Graham
Re: sys.path and htaccess change?
I worked it out. As my change didn't disable the mpservlets caching
system, it was never triggering the module importer again to perform
its own checks. Thus, if I add:
klass, cached_mtime, servlets = self.class_cache.get(fname,
(None,None, []))
# XXX Pretend we didn't find it so mod_python importer used
klass, cached_mtime, servlets = (None,None, [])
# XXX
if not klass or mtime > cached_mtime:
In other words, a bit more work is required in mpservlets as with the
new module importer as it shouldn't really be supplying its own
caching system as that then defeats the mod_python importers own
caching and reloading system.
BTW, if you have program that can display DOT graphs, the graph data
was produced using:
PythonLogHandler ./_loghandler.py
and the following as the log handler.
from mod_python import apache
def loghandler(req):
try:
output = file('/tmp/request.dot', 'w')
output.write(apache.modules_graph(1))
finally:
output.close()
return apache.OK
Seeing the relationships between your modules and the data presented
there can be helpful sometimes in seeing what is happening and working
out how the module importer works.
Graham
On 18/05/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
On 18/05/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> Just change this in your mpservlets package. The new importer can
> handle arbitrary extensions so can load .mps files no problem. With
> just this change your tutorial example works with no problems and it
> uses 'import' to get stuff from handler directory.
>
> kundalini:/usr/local/src/mpservlets-1.1.6 grahamd$ diff
> servlet.py.dist servlet.py
> 1269,1270c1269,1271
> < code = {}
> < execfile(fname, code)
> ---
> > #code = {}
> > #execfile(fname, code)
> > module = apache.import_module(fname)
> 1276c1277,1278
> < klass = code[basename]
> ---
> > #klass = code[basename]
> > klass = getattr(module, basename)
Hmmm, although web pages are being displayed okay, there is something
strange about the scenario in which apache.import_module() is being
used which is meaning that depth searches for changes to child
resulting in reloading from root down isn't working. Thus, if changing
a module which isn't a root module, then I am still needing to restart
Apache which I shouldn't have to with the new module importer. :-(
For example, if I change _SitePage.py in attached graph, then the two
.mps files and _SitePage.py should be reloaded on next request to
either of the .mps files, but it isn't. Looks like I'll have to track
down why as must be missing something very subtle, or obvious, which
is causing the module importer not to behave as expected.
Graham
Re: sys.path and htaccess change?
On 18/05/07, Daniel J. Popowich <[EMAIL PROTECTED]> wrote:
Graham Dumpleton writes:
> Read:
>
> http://www.modpython.org/live/current/doc-html/pyapi-apmeth.html
>
> Especially the area which starts just before:
>
> PythonOption mod_python.importer.path "['~']"
>
> Your particular issue is mentioned just after this example.
Doesn't work, either in .htaccess or in directives. This
is what I have in my apache config:
SetHandler mod_python
PythonHandler mod_python.servlet
PythonOption mod_python.importer.path "['~']"
PythonDebug on
When I go to http://localhost/~dpopowich/py/syspath, a simple
mpservlet that writes out the current value of sys.path, I do NOT see
/home/dpopowich/public_html/py in the path.
You will not see the path listed in sys.path. The mod_python module
importer path and the Python sys.path are deliberately kept separate
because of all the problems caused by each looking in the same
location.
And when I try to import
a python module in that directory, I get import errors.
If you are still using the old module importer in mpservlets to import
your .mps file then that would probably still occur.
However, if I put this in my apache global context:
PythonOption mod_python.legacy.importer *
this fixes my immediate problem.
Is this the way to completely turn this subsystem OFF?
Yes, but the old importer will disappear at some point in the future.
As a side note: I've been away from mod_python for a while and now am
getting back into things and thought one project would be to update
mpservlets to use the new importer I've heard so much about instead of
the one I wrote for mpservlets. I must confess I'm a bit taken aback
that it takes over six pages to document this one function
Considering the list of problems with the old importer came to about
12 pages, I thought it wasn't too bad. :-)
http://www.dscpl.com.au/wiki/ModPython/Articles/ModuleImportingIsBroken
and a quick
read has left me scratching my head and wondering if this is the way I
want to go. I must confess I find it less than intuitive.
Just change this in your mpservlets package. The new importer can
handle arbitrary extensions so can load .mps files no problem. With
just this change your tutorial example works with no problems and it
uses 'import' to get stuff from handler directory.
kundalini:/usr/local/src/mpservlets-1.1.6 grahamd$ diff
servlet.py.dist servlet.py
1269,1270c1269,1271
< code = {}
< execfile(fname, code)
---
#code = {}
#execfile(fname, code)
module = apache.import_module(fname)
1276c1277,1278
< klass = code[basename]
---
#klass = code[basename]
klass = getattr(module, basename)
Graham
Re: TLP Name
On 18/05/07, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]> wrote: On Thu, 17 May 2007, Jim Gallacher wrote: > Quetzalcoatl is still my sentimental favourite. > > Perhaps I'm overly concerned with potential search problems for > Quetzalcoatl, considering that Google is pretty good at figuring out > spelling errors. Also the mod_python name will not disappear, as it'll > still be used as a subproject name, so people can find us that way. Yep. I don't think the TLP itself will be searched for, it's always going to be subprojects, and most likely over time a search for "Apache Python" will take you there (like it does for mod_python currently). And of course there is the spelling correction. I'd tend to agree that the name for the TLP is really only a code name as such and isn't going to be how people search for things. Thus as much as it may take me a while to learn to spell Quetzalcoatl (good thing we have cut and paste), that it is hard to spell is probably not a problem. Also, as for the web site URL for the TLP, I'd suggest we should be okay still using: http://python.apache.org Graham
[jira] Commented: (MODPYTHON-227) PythonOptimize and doc strings.
[ https://issues.apache.org/jira/browse/MODPYTHON-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496169 ] Graham Dumpleton commented on MODPYTHON-227: BTW, workaround at present is to set in environment of Apache user the environment variable: PYTHONOPTIMIZE=1 This will take precedence over the directive due to the order in which things are set. > PythonOptimize and doc strings. > --- > > Key: MODPYTHON-227 > URL: https://issues.apache.org/jira/browse/MODPYTHON-227 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.3.1 >Reporter: Graham Dumpleton >Priority: Minor > > When PythonOptimize directive is used and set to "On", the effect is the same > as if the options '-O -O' had been supplied to the 'python' executable. > Because the highest level of optimisation is enabled, as well as basic > optimisations being enabled, any doc strings in modules are discarded. This > will cause a problem with any Python modules which make use of doc strings in > the way they work. It is suspected for example that this may cause issues > with running 'matplotlib'. See: > http://www.modpython.org/pipermail/mod_python/2007-May/023641.html > for further details. > Because someone may want to enable optimisation but not have doc strings be > discarded, the PythonOptimize directive should perhaps accept 'Basic' and > 'Full' as options instead of just 'On'. For backward compatibility 'On' would > equate to 'Full'. > Note that the documentation is also wrong as it says that PythonOptimize is > only equivalent to '-O'. > Finally, it doesn't currently matter what you set as the value to > PythonOptimize, it always turns the feature on, ie., even if you have: > PythonOptimize Off > The code should check for valid values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-227) PythonOptimize and doc strings.
PythonOptimize and doc strings. --- Key: MODPYTHON-227 URL: https://issues.apache.org/jira/browse/MODPYTHON-227 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton Priority: Minor When PythonOptimize directive is used and set to "On", the effect is the same as if the options '-O -O' had been supplied to the 'python' executable. Because the highest level of optimisation is enabled, as well as basic optimisations being enabled, any doc strings in modules are discarded. This will cause a problem with any Python modules which make use of doc strings in the way they work. It is suspected for example that this may cause issues with running 'matplotlib'. See: http://www.modpython.org/pipermail/mod_python/2007-May/023641.html for further details. Because someone may want to enable optimisation but not have doc strings be discarded, the PythonOptimize directive should perhaps accept 'Basic' and 'Full' as options instead of just 'On'. For backward compatibility 'On' would equate to 'Full'. Note that the documentation is also wrong as it says that PythonOptimize is only equivalent to '-O'. Finally, it doesn't currently matter what you set as the value to PythonOptimize, it always turns the feature on, ie., even if you have: PythonOptimize Off The code should check for valid values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-226) req.status_line should be writable to allow custom status lines.
req.status_line should be writable to allow custom status lines.
Key: MODPYTHON-226
URL: https://issues.apache.org/jira/browse/MODPYTHON-226
Project: mod_python
Issue Type: New Feature
Components: core
Affects Versions: 3.3.1
Reporter: Graham Dumpleton
If req.status_line is writable it allows a handler to return a custom status
line description. For example:
req.status_line = "200 ALL OKAY WITH ME"
req.write('hello world!\n')
return apache.OK
The ability to change the description may be useful in testing. See thread:
http://www.modpython.org/pipermail/mod_python/2007-May/023567.html
for discussion where lack of this feature arose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] does mod_python want to be a TLP
Not necessarily wanting to see this discussion die again, how about just calling it the 'PythonScript' project. Name means it is still obvious and I can't see how we would have issues with a composite name like that as far as PSF trademark goes, but then could be wrong. On 11/05/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote: On 10/05/07, Jim Gallacher <[EMAIL PROTECTED]> wrote: > I like that one. Another, less scientific, possibility might be > pythonalia (python + miscellania). That reminds me of news broadcasts where they talk about police arresting people in possession of drug paraphernalia. :-) In a similar extension though, there is always the 'Apache Pythonistas' project. Where people have mentioned the feather, may be we can call it 'PigeonPy'. This is sort of having a slight dig at the 'CherryPy' symbolism if you get it. For a really obscure reference, try 'Pungi'. I'll let you all work out that one by yourself. Graham
[jira] Created: (MODPYTHON-225) Allow Python executable location and Python home to be specified.
Allow Python executable location and Python home to be specified. - Key: MODPYTHON-225 URL: https://issues.apache.org/jira/browse/MODPYTHON-225 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton Where a user has multiple versions of Python installed getting mod_python to work can be problematic. The main issue is where a version of Python is installed in a location different to where the standard operating system version is installed. For example, if /usr/bin/python is Python version 2.4 and a user has installed Python version 2.5 as /usr/local/bin/python. And the user has compiled mod_python against Python 2.5 and not the operating system version 2.4. Under normal circumstances Apache is only going to look in /usr/bin when started from an init.d script and not in /usr/local/bin. The result of this is that Python when initialised will find /usr/bin/python and assume that that is the base it should use to start with to find where the Python library files are installed. In doing this though it will not be able to find /usr/lib/python2.5 as what it really needs to be able to find is /usr/local/lib/python2.5. The final outcome will be that mod_python will not be able to find the Python code files for itself when starting up. The only way around this is to set the PATH environment variable in the startup scripts for Apache to look in /usr/local/bin before /usr/bin. Alternatively, on some UNIX platforms (but not necessarily all) it is possible to set the environment variable PYTHONEXECUTABLE to be the exact location of the python executable specified when configuring mod_python. Finally, on UNIX platforms one can also set PYTHONHOME to be the exact location of either a shared platform independent/dependent Python library directory, or where separate directories a colon separated list of the two directories. In the latter Python will skip the whole search process and simply use the two values. Having to use environment variables to do this can be a pain as it may be necessary to modify init.d startup scripts to make it work. What should really be done is that mod_python should provide for UNIX platforms the directives PythonExecutable and PythonHome as equivalents to using the PYTHONEXECUTABLE and PYTHONHOME environment variables. These values if defined can be used in calls to Py_SetProgramName() and Py_SetPythonHome() appropriately. This will allow the Apache configuration file itself to be used to qualify which version of Python should be used when non standard versions not in the standard locations are being used. Note that these directives shouldn't be required on the Windows platform as it uses the Windows registry to find where the Python library files are located. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-224) Restrictions on use of signal.signal() to register signal handlers.
Restrictions on use of signal.signal() to register signal handlers. --- Key: MODPYTHON-224 URL: https://issues.apache.org/jira/browse/MODPYTHON-224 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton Apache makes use of signals as an integral part of its process management and shutdown/restart mechanisms. At the minimum it uses the signals SIGTERM, SIGINT, SIGHUP, SIGWINCH and SIGUSR1. Problem is that some Python web frameworks which were originally designed to operate using their own web server still register signal handlers even when not being used on top of their own web server. This is the case with CherryPy and TurboGears (which uses CherryPy). The consequence of any Python package trying to register signal handlers for the above signals is that they interfere with the correct operation of Apache and can causes restarts and shutdowns to fail or not proceed correctly. Since there generally isn't a good reason for any Python package running under mod_python to be registering signal handlers in the first place, to protect against such packages screwing with Apache, it may make sense for mod_python to replace signal.signal() in any interpreters it creates such that signal handler registrations are ignored. A warning message can be logged to indicate that signal handler registration has been prevented. A directive could also be implemented to allow the restriction on registering signal handlers to be removed if still required for some reason. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-223) Make sys.stdout/sys.stderr log properly to Apache error logs.
Make sys.stdout/sys.stderr log properly to Apache error logs. -- Key: MODPYTHON-223 URL: https://issues.apache.org/jira/browse/MODPYTHON-223 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton When sys.stderr or sys.stdout are written to directly, or when the 'print' statement is used without a target file object, any text output will make it into the Apache error log files, but it will only get there after a flush has been performed on stdout/stderr. Most of the time the streams will only be flushed when Apache is being shutdown with the result being that the output is far removed in the log file from any other messages that may have been logged at the same time using the normal Apache error logging functions. Further, anything output via stdout/stderr does not have associated with it the error log prefix giving the time the output was generated. All this can be improved by replacing sys.stderr and sys.stdout with custom Python objects which buffer any output and flushing it through to the Apache error log using the proper ap_log_error() function after each newline is encountered. This will mean that output appears straight away as soon as newline sent and output will be prefixed with date/time string. Do note though that the output cannot be associated with a specific virtual host and thus would go to the main Apache error log file even if each virtual host has its own log file. This is the same as now though when sys.stderr and sys.stdout are used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-222) Support for chunked transfer encoding on request content.
Support for chunked transfer encoding on request content. - Key: MODPYTHON-222 URL: https://issues.apache.org/jira/browse/MODPYTHON-222 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.3.1 Reporter: Graham Dumpleton It is currently not possible to use chunked transfer encoding on request content delivered to a mod_python request handler. The use of chunked transfer encoding is explicitly blocked in C code by: rc = ap_setup_client_block(self->request_rec, REQUEST_CHUNKED_ERROR); To allow chunked transfer encoding instead of REQUEST_CHUNKED_ERROR it would be necessary to supply REQUEST_CHUNKED_DECHUNK. Problem is that it isn't that simple. First off, the problems associated with MODPYTHON-212 have to be fixed with code being able to cope with there being no content length. The next issue is that req.read() method is currently documented as behaving as: If the len argument is negative or omitted, reads all data given by the client. This means that can't have req.read() with no arguments mean give me everything that is currently available in input buffers as everyone currently expects it to return everything sent by client. Thus, to be able to process streaming data one would have to supply an amount of data that one wants to read. The code for that though will always try to ensure that that exact amount of data is read and will block if not enough and not end of input. A handler though may not want it to block and be happy with just getting what is read and only expect it to block if nothing currently available. In other words, the current specification for how req.read() behaves is incompatible with what would be required to support chunked transfer encoding on request content. Not sure how this conflict can be resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-221) Old importer to be removed from code.
Old importer to be removed from code. - Key: MODPYTHON-221 URL: https://issues.apache.org/jira/browse/MODPYTHON-221 Project: mod_python Issue Type: Task Components: importer Affects Versions: 3.3.1 Reporter: Graham Dumpleton The old module importer needs to be removed from code and new importer made the only option. To do this the old importer and dispatch code in apache.py needs to be removed. The dispatch functions in importer.py should then be merged into apache.py. The main importer functionality can probably be left in importer.py. The publisher.py code also has to be updated to use apache.import_module() once more and the cache.py file removed from the source distribution. References to compatibility mode for old importer in documentation also need to be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-220) In PSP pages, 'import' doesn't map through to apache.import_module().
In PSP pages, 'import' doesn't map through to apache.import_module().
-
Key: MODPYTHON-220
URL: https://issues.apache.org/jira/browse/MODPYTHON-220
Project: mod_python
Issue Type: Improvement
Components: psp
Affects Versions: 3.3.1
Reporter: Graham Dumpleton
When Python code appears in SSI files, a trick is performed such that the
Python code in the SSI files is seen as having been originally imported using
the new module importer. This means that if 'import' is used with the Python
code, it will map through to apache.import_module() and first use that
mechanism to try and import code modules. This trick is not performed for PSP
pages however.
What needs to be done for PSP pages is the equivalent of the SSI trick:
class _InstanceInfo:
def __init__(self, label, file, cache):
self.label = label
self.file = file
self.cache = cache
self.children = {}
filter.req.ssi_globals["__file__"] = filter.req.filename
filter.req.ssi_globals["__mp_info__"] = _InstanceInfo(
None, filter.req.filename, None)
filter.req.ssi_globals["__mp_path__"] = []
What this is doing is setting up in the environment of the SSI code object the
magic variables that 'import' hook looks for to allow it to map to
apache.import_module().
If same done in PSP pages then 'import' will map to apache.import_module() for
PSP pages also as first step.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-219) New importer redundantly reloading modules.
New importer redundantly reloading modules. --- Key: MODPYTHON-219 URL: https://issues.apache.org/jira/browse/MODPYTHON-219 Project: mod_python Issue Type: Bug Components: importer Affects Versions: 3.3.1 Reporter: Graham Dumpleton Fix For: 3.3.x Although the new module importer prevents two threads trying to load a module at the same time, the transition from checking to see if a module requires (re)loading to the actual loading isn't properly thread protected and as a result a second thread, although it may decide a module needs (re)loading, isn't simply waiting for the first thread to finish the loading and use the result of that and is instead loading the module again even though no change has been made. This issue was highlighted in following mailing list posts: http://www.modpython.org/pipermail/mod_python/2007-May/023583.html http://www.modpython.org/pipermail/mod_python/2007-May/023586.html Further discussion can be found in the associated posts for that thread in the archives. Note that this only affects multithreaded Apache MPMs and the window for this to happen is very small and is only going to occur under heavy load from multiple clients or in web pages where multiple requests may be made from a page to a resource requiring the same code module be loaded. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ https://issues.apache.org/jira/browse/MODPYTHON-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494960 ] Graham Dumpleton commented on MODPYTHON-195: This changes also possibly prevents Apache being run in single process mode on Windows when mod_python is loaded. This is because Python will not be initialised in the single process and when a request arrives for mod_python it will fail. > Possible leaking of Win32 event handles when Apache restarted. > -- > > Key: MODPYTHON-195 > URL: https://issues.apache.org/jira/browse/MODPYTHON-195 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.10, 3.3.1 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3.x > > > 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. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MODPYTHON-109) Signal handler calling Py_Finalize() when child processes being killed.
[ https://issues.apache.org/jira/browse/MODPYTHON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton updated MODPYTHON-109: --- Fix Version/s: (was: 3.3.1) > Signal handler calling Py_Finalize() when child processes being killed. > --- > > Key: MODPYTHON-109 > URL: https://issues.apache.org/jira/browse/MODPYTHON-109 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.7 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Attachments: MP109_20060308_grahamd_1.diff > > > 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. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ https://issues.apache.org/jira/browse/MODPYTHON-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton updated MODPYTHON-195: --- Fix Version/s: (was: 3.3.1) 3.3.x Affects Version/s: 3.3.1 > Possible leaking of Win32 event handles when Apache restarted. > -- > > Key: MODPYTHON-195 > URL: https://issues.apache.org/jira/browse/MODPYTHON-195 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.10, 3.3.1 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3.x > > > 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. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MODPYTHON-218) Access to additional Apache functions and request_rec fields
[ https://issues.apache.org/jira/browse/MODPYTHON-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton updated MODPYTHON-218: --- Fix Version/s: (was: 3.3.1) Affects Version/s: 3.3.1 > Access to additional Apache functions and request_rec fields > > > Key: MODPYTHON-218 > URL: https://issues.apache.org/jira/browse/MODPYTHON-218 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.3.1 > Environment: all >Reporter: Richard Barrett > > I have available a patch file which enhances mod_python-3.3.1 source version > as described below. How do I submit this for consideration? > 1. Added support for the following methods in requestobject.c: > Referring to http://docx.itscales.com/http__request_8h.html: > lookup_file - provides access to ap_sub_req_lookup_file > lookup_method_uri - provides access to ap_sub_req_method_uri > lookup_uri - provides access to ap_sub_req_method_uri > Referring to > http://docx.itscales.com/group___a_p_a_c_h_e___c_o_r_e___p_r_o_t_o.html > note_basic_auth_failure - provides access to ap_note_basic_auth_failure > 2. Added checks on values passed to function setreq_recmbr in requestobject.c > for assignment to the following request variable: > method - this function coerces both the method and method_number to the > appropriate values for the string value passed in as a parameter > 3. Added the function conn_close in connobject.c so that I can force the > connection to not be kept alive for another request; sets the value of the > conn_rec's keepalive field to AP_CONN_CLOSE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] does mod_python want to be a TLP
On 10/05/07, Jim Gallacher <[EMAIL PROTECTED]> wrote: I like that one. Another, less scientific, possibility might be pythonalia (python + miscellania). That reminds me of news broadcasts where they talk about police arresting people in possession of drug paraphernalia. :-) In a similar extension though, there is always the 'Apache Pythonistas' project. Where people have mentioned the feather, may be we can call it 'PigeonPy'. This is sort of having a slight dig at the 'CherryPy' symbolism if you get it. For a really obscure reference, try 'Pungi'. I'll let you all work out that one by yourself. Graham
[jira] Reopened: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ https://issues.apache.org/jira/browse/MODPYTHON-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton reopened MODPYTHON-195: The change for this appears to be having the side affect of the mod_python/Python version information not showing up in the Apache startup string. This is based on logging shown in email: http://www.modpython.org/pipermail/mod_python/2007-May/023582.html Where would would expect to see something like: Apache/2.2.4 (Win32) mod_python/3.3.1 Python/2.5 PHP/5.2.1 configured -- resuming normal operations on Windows one is only seeing: Apache/2.2.4 (Win32) PHP/5.2.1 This is because the version information is output in the first Windows process created, but the change is stopping the code which composes the version information from being run. The code should be reorganised so that calls to ap_add_version_component() for mod_python and Python are always done. When done second time it is redundant but doesn't matter. > Possible leaking of Win32 event handles when Apache restarted. > -- > > Key: MODPYTHON-195 > URL: https://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. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] does mod_python want to be a TLP
On 10/05/07, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]> wrote: 1. "Python" is not a good name for this project because "Apache Python" will just be too confusing and probably infringes on a PSF trademark. So if you have any creative suggestions, send them in, don't be shy, even if you think they may sound a little stupid at first :-) How about 'Asphyxia'. This being the outcome if a Python gets you. :-) Since the reason for the TLP being for Python rather than just mod_python was the idea there might be more than just the mod_python project, ie., other Apache/Python modules, then maybe call it 'Pythonidae'. This is the more technical name for the family of snakes which people call Pythons. Not sure how you are meant to pronounce that though. Graham
[jira] Commented: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
[ https://issues.apache.org/jira/browse/MODPYTHON-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494242 ] Graham Dumpleton commented on MODPYTHON-202: mod_python should perhaps simply be using 'ap_accept_lock_mech' instead of 'APR_LOCK_DEFAULT'. The value of 'ap_accept_lock_mech' is more likely by default to be correct for what type of MPM is being used, if not, it can be overridden using the existing AcceptMutex directive, which if 'APR_LOCK_DEFAULT' is wrong for the MPM being used would have to be done to get the MPM to work anyway. > Allow mechanism used by global mutex locks to be specified. > --- > > Key: MODPYTHON-202 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-207) The attribute req.args should be modifiable.
[ https://issues.apache.org/jira/browse/MODPYTHON-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-207. -- > The attribute req.args should be modifiable. > > > Key: MODPYTHON-207 > URL: https://issues.apache.org/jira/browse/MODPYTHON-207 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.3 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > For completeness, the req.args attribute should be modifiable. Updating > req.args is done in modules like mod_rewrite and so something that emulates > that may find it useful. It also may be necessary when wishing to interact > with mod_proxy where one wants to add additional query args to the request as > it is passed through to the downstream web server. > One use within mod_python itself may be to allow GET style query args when a > POST request has been submitted to be wiped out before util.FieldStorage is > used to process form fields. This would avoid using the hack approach of > creating a wrapper class around the request object which returns an empty > string when req.args is accessed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-206) The attribute req.used_path_info should be writable.
[
https://issues.apache.org/jira/browse/MODPYTHON-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-206.
--
> The attribute req.used_path_info should be writable.
>
>
> Key: MODPYTHON-206
> URL: https://issues.apache.org/jira/browse/MODPYTHON-206
> Project: mod_python
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.3
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> At present, req.used_path_info is read only. This should instead be
> modifiable as well.
> This attribute gets set when you use the Apache AcceptPathInfo directive. You
> might use it for example as:
>
> Options +Includes
> SetOutputFilter INCLUDES
> AcceptPathInfo On
>
> In this case use of AcceptPathInfo would be needed as the default-handler for
> serving up static files prohibits additional path info by default. Thus, if
> you want SSI files to be able to make use of additional path info, you have
> to enable it.
> In mod_python 3.3, the ability to register filters dynamically just for the
> current request means that SSI can be set up from within a fixuphandler using:
> def fixuphandler(req):
> if os.path.basename(req.filename) == 'mypaths.shtml':
> req.add_output_filter('INCLUDES')
> return apache.OK
> Without req.used_path_info being modifiable though, one can't do the
> equivalent to AcceptPathInfo from within the handler. Thus,
> req.used_path_info should be modifiable. The values this attribute needs to
> be set to are already specified in mod_python.apache
> and thus only needs one line change to requestobject.c because value is an
> integer. The handler could then be written as:
> def fixuphandler(req):
> if os.path.basename(req.filename) == 'mypaths.shtml':
> req.add_output_filter('INCLUDES')
> req.used_path_info = apache.AP_REQ_ACCEPT_PATH_INFO
> return apache.OK
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-200) Can't use signed and marshalled cookies together.
[
https://issues.apache.org/jira/browse/MODPYTHON-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-200.
--
> Can't use signed and marshalled cookies together.
> -
>
> Key: MODPYTHON-200
> URL: https://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.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-196) Add req.server.log_error() and req.connection.log_error().
[ https://issues.apache.org/jira/browse/MODPYTHON-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-196. -- > Add req.server.log_error() and req.connection.log_error(). > -- > > Key: MODPYTHON-196 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-198) Python 2.5 nested auth functions in publisher.
[
https://issues.apache.org/jira/browse/MODPYTHON-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-198.
--
> Python 2.5 nested auth functions in publisher.
> --
>
> Key: MODPYTHON-198
> URL: https://issues.apache.org/jira/browse/MODPYTHON-198
> Project: mod_python
> Issue Type: Bug
> Components: publisher
>Affects Versions: 3.2.10
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> Jim Gallacher wrote:
> With python 2.5 I get 2 failures:
> test_publisher_auth_nested
> test_publisher_auth_method_nested
> It looks like something has changed in python 2.5 introspection that is
> messing up publisher.
> Test script testme.py
> -
> def testfunc():
> print 'stuff'
> def __auth__():
> print '__auth__ called'
> def __access__():
> print '__access__ called'
> def main():
> func_obj = testfunc
> func_code = func_obj.func_code
> print func_code.co_names
> if __name__ == '__main__':
> main()
> Results
> ---
> $ python2.3 testme.py
> ('__auth__', '__access__')
> $ python2.4 testme.py
> ('__auth__', '__access__')
> $ python2.5 testme.py
> ()
> Dan Eloff points out that information is now in co_varnames.
> >>> fc.co_names
> ()
> >>> fc.co_varnames
> ('__auth__', '__access__')
> >>> def foo(a,b):
> d = 5
> def bar(c):
> return c
> >>> fc.co_names
> ()
> >>> fc.co_varnames
> ('a', 'b', 'd', 'bar')
> To get just args, try:
> >>> fc.co_varnames[:fc.co_argcount]
> ('a', 'b')
> And for just local vars:
> >>> fc.co_varnames[fc.co_argcount:]
> ('d', 'bar')
> Still need to work out if actual code objects for the functions are available
> in co_consts or not. Ie., need to replace:
> 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__, func_globals)
> found_auth = 1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ https://issues.apache.org/jira/browse/MODPYTHON-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-195. -- > Possible leaking of Win32 event handles when Apache restarted. > -- > > Key: MODPYTHON-195 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-193) Add req.hlist.location to mirror req.hlist.directory.
[ https://issues.apache.org/jira/browse/MODPYTHON-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-193. -- > Add req.hlist.location to mirror req.hlist.directory. > - > > Key: MODPYTHON-193 > URL: https://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 is. > Thus, if req.hlist.location can be supplied, this would solve this problem. In > respect of apache.get_handler_root(), am not sure there really should be an > equivalent within the apache module as knowing the location at the time of > import sounds a bit dubious to me even if it m
[jira] Closed: (MODPYTHON-194) Memory leak due to not clearing thread state object before deletion.
[ https://issues.apache.org/jira/browse/MODPYTHON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-194. -- > Memory leak due to not clearing thread state object before deletion. > > > Key: MODPYTHON-194 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-189) repr() for various objects doesn't convert data members correctly.
[
https://issues.apache.org/jira/browse/MODPYTHON-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-189.
--
> repr() for various objects doesn't convert data members correctly.
> --
>
> Key: MODPYTHON-189
> URL: https://issues.apache.org/jira/browse/MODPYTHON-189
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3, 3.2.10
> Reporter: Graham Dumpleton
>Priority: Minor
> Fix For: 3.3
>
>
> The repr() methods of various objects, eg., tableobject, use code like:
> PyString_ConcatAndDel(&s, PyString_FromString("'"));
> PyString_ConcatAndDel(&s, PyString_FromString(elts[i].key));
> PyString_ConcatAndDel(&s, PyString_FromString("': '"));
> PyString_ConcatAndDel(&s, PyString_FromString(elts[i].val));
> PyString_ConcatAndDel(&s, PyString_FromString("'"));
> to construct the string. This doesn't though consider that values could have
> quotes in them.
> Instead of outputting quotes and string in between, should use something like:
>t = PyString_FromString(elts[i].val);
>PyString_ConcatAndDel(&s, PyObject_Repr(t));
>Py_XDECREF(t);
> Ie., let the repr() routine of the string to quote as appropriate.
> Since the repr() outputs of these objects are only used for debugging and
> can't be used to reconstruct objects, not too big a deal, but should be
> addressed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-191) Tampering with signed cookies.
[ https://issues.apache.org/jira/browse/MODPYTHON-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-191. -- > Tampering with signed cookies. > -- > > Key: MODPYTHON-191 > URL: https://issues.apache.org/jira/browse/MODPYTHON-191 > 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 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-187) Hang on subscripted access to request.subprocess_env.
[
https://issues.apache.org/jira/browse/MODPYTHON-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-187.
--
> Hang on subscripted access to request.subprocess_env.
> -
>
> Key: MODPYTHON-187
> URL: https://issues.apache.org/jira/browse/MODPYTHON-187
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.10
> Environment: Apache: 2.0.59
> ModPython: 3.2.10
> Python: 2.4
> OS: Windows Server 2003
>Reporter: Alan Kennedy
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
> Attachments: MP187-2006-08-28-jgallacher-1.diff
>
>
> When subscripted access is used to access variable 'SCRIPT_FILENAME' in the
> request.subprocess_env table/mapping, the code hangs.
> The following snippet illustrates the problem.
> # -=-=-=-=-=-=
> def postreadrequesthandler(request):
> request.add_common_vars()
> value = request.subprocess_env['SCRIPT_FILENAME']# This hangs
> # value = request.subprocess_env.get('SCRIPT_FILENAME')# This works
> return apache.OK
> # -=-=-=-=-=-=
> The strange thing is that the .get() access works fine: only the subscript
> hangs?
> If anyone is wondering about a use-case, I don't actually have one. I was
> just iterating over the contents of the request.subprocess_env using a for
> loop (code below), and found that the code hung when accessing
> 'SCRIPT_FILENAME', and not for any other variable.
> # -=-=-=
> request.add_common_vars()
> d = {}
> for sek in request.subprocess_env.keys():
> d[sek] = request.subprocess_env[sek]
> # -=-=-=
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-185) _psp.parsestring doesn't check for empty values
[ https://issues.apache.org/jira/browse/MODPYTHON-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-185. -- > _psp.parsestring doesn't check for empty values > --- > > Key: MODPYTHON-185 > URL: https://issues.apache.org/jira/browse/MODPYTHON-185 > Project: mod_python > Issue Type: Bug > Components: psp > Environment: All >Reporter: Thomas Hervé > Assigned To: Jim Gallacher >Priority: Minor > Fix For: 3.3 > > Attachments: _pspmodule.diff > > > The function _psp_module_parsestring of _pspmodule.c doesn't check the value > of parser->pycode.blob when calling PyString_FromString (whereas it's done in > _psp_module_parse). When called with an empty string it can cause a segfault > (blob is NULL and PyString_FromString doesn't check for NULL value). > I attach a simple diff correcting the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-184) Memory leak apache.table()
[
https://issues.apache.org/jira/browse/MODPYTHON-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-184.
--
> Memory leak apache.table()
> --
>
> Key: MODPYTHON-184
> URL: https://issues.apache.org/jira/browse/MODPYTHON-184
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3, 3.2.10
>Reporter: Jim Gallacher
> Assigned To: Jim Gallacher
> Fix For: 3.3
>
> Attachments: MP184-2006-08-25-grahamd-1.diff
>
>
> There is a memory leak in apache.table().
> from mod_python import apache
> def handler(req):
> req.content_type = 'text/plain'
> t = apache.make_table()
> req.write('ok table:')
> return apache.OK
> Using mpm-worker with StartServers 2, and 2 requests results in memory
> consumption going from 1.2% to 9.3% per process. (ie approx 8k per request)
> This will have an impact on FieldStorage which makes use of
> apache.make_table(), which is the deprecated name for apache.table()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-182) Memory leak in request readline()
[
https://issues.apache.org/jira/browse/MODPYTHON-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-182.
--
> Memory leak in request readline()
> -
>
> Key: MODPYTHON-182
> URL: https://issues.apache.org/jira/browse/MODPYTHON-182
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3, 3.2.x, 3.2.10
> Environment: Apache 2.0.55 mpm-worker
>Reporter: Jim Gallacher
> Assigned To: Jim Gallacher
> Fix For: 3.3
>
>
> There is at least one memory leak request.readline(). I'm currently auditing
> the code so there may well be others.
> I think the leak will only occur when the request body is incompletely read
> with readline, which is likely an unusual corner case. The following
> demostrates the leak:
> Consider a request body consisting of:
> '\n'.join([ 'a'*100 for i in xrange(0, 100) ])
> and using this handler:
> def handler(req):
> # Handler reads 20 lines but request contains 100 lines.
> # Since the body is not completely read, the buffer allocated
> # in requestobject.c req_readline is never freed.
> req.content_type = 'text/plain'
> count = 0
> for i in range(0, 20):
> line = req.readline()
> count += 1
> req.write('ok readline_partial: %d lines read' % count)
> return apache.OK
> With this test setup I'm seeing a leak of approx 10k bytes per request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-181) Memory leak when using handlers in multiple phases at same time.
[
https://issues.apache.org/jira/browse/MODPYTHON-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-181.
--
> Memory leak when using handlers in multiple phases at same time.
>
>
> Key: MODPYTHON-181
> URL: https://issues.apache.org/jira/browse/MODPYTHON-181
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.1.4, 3.3, 3.2.8
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> When using handlers against multiple phases, ie.,
> # .htaccess
> PythonFixupHandler handlers
> AddHandler mod_python .py
> PythonHandler handlers
> # handlers.py
> from mod_python import apache
> def handler(req):
> req.content_type = 'text/plain'
> req.write('handler')
> return apache.OK
> def fixuphandler(req):
> return apache.OK
> mod_python will leak memory on each request, which Apache child process sizes
> blowing out quite quickly.
> The problem code is in python_handler() in 'src/mod_python.c'. Specifically
> the code does:
> if (!hle) {
> /* create a handler list object from dynamically registered handlers
> */
> request_obj->hlo = (hlistobject *)MpHList_FromHLEntry(dynhle, 1);
> }
> else {
> /* create a handler list object */
> request_obj->hlo = (hlistobject *)MpHList_FromHLEntry(hle, 1);
> /* add dynamically registered handlers, if any */
> if (dynhle) {
> MpHList_Append(request_obj->hlo, dynhle);
> }
> }
> Problem is that request_obj->hlo can already be set by a prior phase's
> handler and by simply assigning to request_obj->hlo you get a memory leak as
> it refers to an existing Python object and it isn't being decref'd.
> Thus, before this 'if' statement, it would appear that the following should
> be inserted.
> if (request_obj->hlo)
> Py_DECREF(request_obj->hlo);
> or:
> Py_XDECREF(request_obj->hlo);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-180) publisher wrongly generating warning that there is 'nothing to publish'
[
https://issues.apache.org/jira/browse/MODPYTHON-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-180.
--
> publisher wrongly generating warning that there is 'nothing to publish'
> ---
>
> Key: MODPYTHON-180
> URL: https://issues.apache.org/jira/browse/MODPYTHON-180
> Project: mod_python
> Issue Type: Bug
> Components: publisher
>Affects Versions: 3.3
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> Publisher handler contains the code:
> # we log a message if nothing was published, it helps with debugging
> if (not published) and (req.bytes_sent==0) and (req.next is None):
> log=int(req.get_config().get("PythonDebug", 0))
> if log:
> req.log_error("mod_python.publisher: nothing to publish.")
> The idea is that if the publisher didn't generate any output and simply
> returned None, that a warning would be generated which might be noticed by a
> developer and thus be helpful to debugging problems.
> Problem is that "req.bytes_sent" is only actually non zero when data is
> flushed and actually written back to the client by Apache. It does not take
> into consideration any buffered data.
> In other words, if "req.write()" is used but second optional argument is
> always being set to 0 indicating that data should not be flushed, then
> publisher will wrongly say nothing actually got published.
> Because the PSP classes are no longer flushing data so that output filters
> like "CONTENT_LENGTH" will work, this will mean you will get this warning all
> the time when using code like:
> from mod_python import apache, psp
> def index(req):
> page = psp.PSP(req, 'echo.psp')
> page.run()
> Question is, is there a way to determine from Apache that there is buffered
> data. We don't really want to be adding another special flag in the
> mod_python request wrapper like req._content_type_set do we???
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-179) req.readlines(sizehint) does not work correctly
[
https://issues.apache.org/jira/browse/MODPYTHON-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-179.
--
> req.readlines(sizehint) does not work correctly
> ---
>
> Key: MODPYTHON-179
> URL: https://issues.apache.org/jira/browse/MODPYTHON-179
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.8
> Environment: All
>Reporter: Jim Gallacher
> Assigned To: Jim Gallacher
>Priority: Minor
> Fix For: 3.3
>
>
> A bug in req_readlines(sizehint) in requestobject.c causes output to be
> returned prematurely for any value of the optional sizehint argument.
> The faulty bit of code is:
> line = req_readline(self, rlargs);
> while (line && (PyString_Size(line)>0)) {
> PyList_Append(result, line);
> size += PyString_Size(line);
> if ((sizehint != -1) && (size >= size))
> break;
> line = req_readline(self, args);
> }
> Since (size >= size) will always be true, reading the input stream will end
> prematurely for any value of sizehint != -1.
> This code will fix the problem.
> --- requestobject.c (revision 417294)
> +++ requestobject.c (working copy)
> @@ -1154,7 +1154,7 @@
> while (line && (PyString_Size(line)>0)) {
> PyList_Append(result, line);
> size += PyString_Size(line);
> -if ((sizehint != -1) && (size >= size))
> +if ((sizehint != -1) && (size >= sizehint))
> break;
> line = req_readline(self, args);
> }
> Once that is fixed the documentation needs to be revised, as it does not
> accurately reflect the behaviour of the code.
> Currently the docs are:
> """Reads all or up to sizehint bytes of lines using readline and returns a
> list of the lines read."""
> whereas the code can read beyond sizehint. The total read could actually be
> sizehint + len(line) where line is the last line read.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-178) mod_python.psp should return 404 and not 500 when PSP file doesn't exist.
[ https://issues.apache.org/jira/browse/MODPYTHON-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-178. -- > mod_python.psp should return 404 and not 500 when PSP file doesn't exist. > - > > Key: MODPYTHON-178 > URL: https://issues.apache.org/jira/browse/MODPYTHON-178 > Project: mod_python > Issue Type: Improvement >Affects Versions: 3.2.8 > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > When using mod_python.psp, if a request is made against a .psp file which > doesn't exist, then a 500 error response is returned. If PythonDebug is on, > the response is of the form: > Mod_python error: "PythonHandler mod_python.psp" > Traceback (most recent call last): > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py", > line 385, in HandlerDispatch > result = object(req) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/psp.py", > line 302, in handler > p = PSP(req) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/psp.py", > line 111, in __init__ > self.load_from_file() > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/psp.py", > line 164, in load_from_file > raise ValueError, "%s is not a file" % filename > ValueError: /Users/grahamd/Workspaces/testing/psp-1/bar.psp is not a file > Instead of returning a 500 error, mod_python.psp should identify that target > of request does not exist and return a 404 (NOT_FOUND) error response instead. > Note that this will need to cope with requests against .psp_ file when > PythonDebug on and SetHandler being used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-176) PSP.run() should not unlock session if it didn't create it.
[ https://issues.apache.org/jira/browse/MODPYTHON-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-176. -- > PSP.run() should not unlock session if it didn't create it. > --- > > Key: MODPYTHON-176 > URL: https://issues.apache.org/jira/browse/MODPYTHON-176 > Project: mod_python > Issue Type: Improvement >Affects Versions: 3.2.8 > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton >Priority: Minor > Fix For: 3.3 > > > When PSP.run() is exiting, it unlocks the session even if it had not created > the session object in the first place. In other words, it still unlocks the > session if it was inherited by using that already stored as req.session. > By rights it should not unlock the session object when it is inherited from > req.session as that causes limitations when PSP objects are being used > explicitly as a templating system from publisher or other handlers. > Specifically, it would prevent the handler which used the PSP object making > changes to the session object after PSP.run() has been called and then doing > a subsequent save of the session. > That session locks should not perhaps be unlocked by PSP.run() was first > mentioned in MODPYTHON-38. Note that the session still gets unlocked, but by > a cleanup handler registered by the session object when it was first created. > At the same time, it could be said that PSP.run() shouldn't call save on the > session automatically when the session object is inherited and that the save > should be left up to the handler making use of the PSP object in these > situations. Existing use of the PSP objects would need to be evaluated to > determine if disabling autosave would cause issues for existing code if such > a change were to be made for when session object inherited. A better option > may be to add an additional argument run PSP.run() called autosave which > defaults to True to preserve existing behaviour, but allow explicit users of > PSP objects to change the behaviour if required. This all gets a bit > complicated when error pages come into the picture though, so more thought > needed on this latter point of autosave. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-218) Access to additional Apache functions and request_rec fields
[ https://issues.apache.org/jira/browse/MODPYTHON-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492821 ] Graham Dumpleton commented on MODPYTHON-218: Attach your patch to this issue. Also get yourself subscribed to the developer mailing list described in: http://wiki.apache.org/mod_python/Mailing_lists and bring the issue up there if you want to get feedback. Personally I believe it is just becoming too unwieldy to keep adding extra functions on an ad-hoc basis. I believe effort should be directed to a SWIG binding for Apache. Unfortunately such a beast can't really be harnessed by mod_python itself because it would be too much trouble to make it backwards compatible and would just make the mod_python code base even harder to maintain. As a separate package though it is realistic and I do actually have most of such a SWIG binding done. > Access to additional Apache functions and request_rec fields > > > Key: MODPYTHON-218 > URL: https://issues.apache.org/jira/browse/MODPYTHON-218 > Project: mod_python > Issue Type: Improvement > Components: core > Environment: all >Reporter: Richard Barrett > Fix For: 3.3 > > > I have available a patch file which enhances mod_python-3.3.1 source version > as described below. How do I submit this for consideration? > 1. Added support for the following methods in requestobject.c: > Referring to http://docx.itscales.com/http__request_8h.html: > lookup_file - provides access to ap_sub_req_lookup_file > lookup_method_uri - provides access to ap_sub_req_method_uri > lookup_uri - provides access to ap_sub_req_method_uri > Referring to > http://docx.itscales.com/group___a_p_a_c_h_e___c_o_r_e___p_r_o_t_o.html > note_basic_auth_failure - provides access to ap_note_basic_auth_failure > 2. Added checks on values passed to function setreq_recmbr in requestobject.c > for assignment to the following request variable: > method - this function coerces both the method and method_number to the > appropriate values for the string value passed in as a parameter > 3. Added the function conn_close in connobject.c so that I can force the > connection to not be kept alive for another request; sets the value of the > conn_rec's keepalive field to AP_CONN_CLOSE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-161) Wrong interpreter chosen with req.add_handler()/PythonInterpPerDirective.
[
https://issues.apache.org/jira/browse/MODPYTHON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-161.
--
> Wrong interpreter chosen with req.add_handler()/PythonInterpPerDirective.
> -
>
> Key: MODPYTHON-161
> URL: https://issues.apache.org/jira/browse/MODPYTHON-161
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> Having fixed MODPYTHON-160, if using:
> # .htaccess
> SetHandler mod_python
> PythonInterpPerDirective On
> PythonFixupHandler interpreter_1
> # interpreter_1.py
> from mod_python import apache
> import os, sys
> directory = os.path.dirname(__file__)
> def fixuphandler(req):
> req.log_error("fixuphandler")
> req.log_error("interpreter=%s"%req.interpreter)
> req.log_error("directory=%s"%req.hlist.directory)
> req.add_handler("PythonHandler","interpreter_1",directory)
> return apache.OK
> def handler(req):
> req.log_error("handler")
> req.log_error("interpreter=%s"%req.interpreter)
> req.log_error("directory=%s"%req.hlist.directory)
> req.content_type = 'text/plain'
> req.write('hello')
> return apache.OK
> when select_interp_name() in src/mod_python.c tries to determine the
> interpreter name, for PythonInterPerDirective, it will use the value as
> supplied as directory argument to req.add_handler(). In doing this though, it
> doesn't consider the fact that the directory may not have a trailing slash
> and since interpreter names for PythonInterpPerDirective always have a
> trailing slash, the handler will not be executed in correct interpreter
> context.
> [Sun Apr 16 17:20:00 2006] [notice] mod_python: (Re)importing module
> 'interpreter_1'
> [Sun Apr 16 17:20:00 2006] [error] [client ::1] fixuphandler
> [Sun Apr 16 17:20:00 2006] [error] [client ::1]
> interpreter=/Users/grahamd/Workspaces/testing/interpreter-1/
> [Sun Apr 16 17:20:00 2006] [error] [client ::1]
> directory=/Users/grahamd/Workspaces/testing/interpreter-1/
> [Sun Apr 16 17:20:00 2006] [notice] mod_python: (Re)importing module
> 'interpreter_1'
> [Sun Apr 16 17:20:00 2006] [error] [client ::1] handler
> [Sun Apr 16 17:20:00 2006] [error] [client ::1]
> interpreter=/Users/grahamd/Workspaces/testing/interpreter-1
> [Sun Apr 16 17:20:00 2006] [error] [client ::1]
> directory=/Users/grahamd/Workspaces/testing/interpreter-1
> A further problem is that normally the path indicating where a directive was
> defined is internally calculated from Apache configuration and thus always
> uses POSIX directory conventions, ie., forward slash. If the above code were
> run on Win32, the directory calculated from __file__ is going to most likely
> use DOS directory conventions, ie., backward slash. Thus, even if a trailing
> slash were to be added, it still will not work because the remainder of the
> path is going to use backward slash and thus the interpreter name still will
> not match what it probably should be.
> The main purpose of the directory argument to req.add_handler() is to know
> where to find the module referenced in the handler argument. In this case it
> is also used to determine the Python interpreter name. The fix may be that
> the interpreter name be determined in some other way based on the interpreter
> in use when the req.add_handler() call was made.
> This is just part of problems I can possibly see with calculation of
> interpreter names for handlers. More on this another time. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-175) PSP error page accessing session object can cause a deadlock.
[ https://issues.apache.org/jira/browse/MODPYTHON-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-175. -- > PSP error page accessing session object can cause a deadlock. > - > > Key: MODPYTHON-175 > URL: https://issues.apache.org/jira/browse/MODPYTHON-175 > Project: mod_python > Issue Type: Bug >Affects Versions: 3.2.8 > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > If a session object is required for a PSP page, the session object will be > created automatically with the session being locked at the same time, when > PSP.run() is called. If an error page is generated by the session page it in > turn will then be run. The problem is that the session lock is still held by > the main page and thus if the error page itself tries to also access the > session object, when the PSP.run() method of the error page is called, it > will create a new instance of the session object which will result in a > deadlock. > In MODPYTHON-38, the suggested change was that when PSP.run() creates the > session object that it assign it back to req.session. This change was not > made, but if it was then when the error page was run, it would simply have > inherited the session object which had already been created by the main page > and a deadlock would not have ensued. > Thus could should read as: > session = None > if "session" in code.co_names: > if hasattr(req, 'session'): > session = req.session > else: > req.session = session = Session.Session(req) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-174) Update requirements to Apache 2.0.47 or greater
[ https://issues.apache.org/jira/browse/MODPYTHON-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-174. -- > Update requirements to Apache 2.0.47 or greater > --- > > Key: MODPYTHON-174 > URL: https://issues.apache.org/jira/browse/MODPYTHON-174 > Project: mod_python > Issue Type: Task > Components: documentation >Affects Versions: 3.2.x, 3.2.7, 3.2.8 >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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-164) Allow req.add_handler()/req.register_*_filter() to take module/function for handler.
[
https://issues.apache.org/jira/browse/MODPYTHON-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-164.
--
> Allow req.add_handler()/req.register_*_filter() to take module/function for
> handler.
>
>
> Key: MODPYTHON-164
> URL: https://issues.apache.org/jira/browse/MODPYTHON-164
> Project: mod_python
> Issue Type: New Feature
> Components: core
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-173) DbmSession creates world readable db file
[ https://issues.apache.org/jira/browse/MODPYTHON-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-173. -- > DbmSession creates world readable db file > - > > Key: MODPYTHON-173 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-172) Memory leak with util.fieldstorage using mod_python 3.2.8 on apache 2.0.55
[ https://issues.apache.org/jira/browse/MODPYTHON-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-172. -- > Memory leak with util.fieldstorage using mod_python 3.2.8 on apache 2.0.55 > -- > > Key: MODPYTHON-172 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-171) Assignment to req.filename and POSIX style pathnames.
[ https://issues.apache.org/jira/browse/MODPYTHON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-171. -- > Assignment to req.filename and POSIX style pathnames. > - > > Key: MODPYTHON-171 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-170) Allow access to request_rec/server_rec/conn_rec/filter_rec as Python CObject.
[
https://issues.apache.org/jira/browse/MODPYTHON-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-170.
--
> Allow access to request_rec/server_rec/conn_rec/filter_rec as Python CObject.
> -
>
> Key: MODPYTHON-170
> URL: https://issues.apache.org/jira/browse/MODPYTHON-170
> Project: mod_python
> Issue Type: New Feature
> Components: core
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> At the moment, if mod_python doesn't expose a feature of Apache that you may
> want to use, you are stuffed and either have to convince mod_python
> maintainers to add it, patch your mod_python or create a Python loadable
> module that builds against both mod_python headers and Apache headers.
> In the latter, it needs access to mod_python headers so as to be able to look
> inside the mod_python requestobject to get at the request_rec Apache
> structure. In practice, the only thing from the mod_python requestobject that
> such a extension module is going to want, is the request_rec structure, thus
> it is probably simpler and makes building such an extension easier, if the
> mod_python requestobject provided a "request_rec" attribute which was a
> Python CObject wrapper which wrapped the C request_rec pointer. Similarly,
> access to server_rec/conn_rec/filter_rec could also be provided.
> For example, you might have a C extension function like:
> typedef int (*ssl_is_https_t)(conn_rec*);
> static PyObject* is_https(PyObject* module, PyObject* args)
> {
> PyObject* req_object = 0;
> request_rec* req;
> ssl_is_https_t ssl_is_https = 0;
> int result = 0;
> if (!PyArg_ParseTuple(args,"O",&req_object))
> return 0;
> if (! PyCObject_Check(req_object))
> PyErr_SetString(PyExc_TypeError,"not a CObject");
> req = PyCObject_AsVoidPtr(req_object);
> ssl_is_https = (ssl_is_https_t)apr_dynamic_fn_retrieve("ssl_is_https");
> if (ssl_is_https == 0)
> return Py_BuildValue("i",0);
> result = ssl_is_https(req->connection);
> return Py_BuildValue("i",result);
> }
> The call to this form Python code would be:
> import myextension
> def handler(req):
> if myextension.is_https(req.request_rec):
>...
> Note that something like this was posted some time back:
> http://www.modpython.org/pipermail/mod_python/2006-February/020340.html
> but the problem with it was that it needed the mod_python header files when
> compiling. Using the Python CObject avoids that. Any Python distutils
> setup.py file still needs to know where the Apache header files etc are, but
> it can use apxs to get that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-168) psp_parser fails when CR is used as a line terminator
[
https://issues.apache.org/jira/browse/MODPYTHON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-168.
--
> psp_parser fails when CR is used as a line terminator
> -
>
> Key: MODPYTHON-168
> URL: https://issues.apache.org/jira/browse/MODPYTHON-168
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3
> Environment: Mac OS X using older GoLive editor
>Reporter: Jim Gallacher
> Assigned To: Jim Gallacher
>Priority: Minor
> Fix For: 3.3
>
>
> As reported by Jeff Zelt:
> """
> On Mac OS X, make sure that your HTML files are terminated by :
>a line feed (ascii 10) and NOT a carriage return (ascii 13).
> PSP does *not* like lines terminated by only a carriage return.
> The problem was that I was using Adobe GoLive to edit my web pages and to
> insert the python code in the page (I am talking about the source view, not
> the WYSIWYG/Layout view). My version of GoLive is a little old and still
> prefers to write files with carriage return line endings. This was the
> default for the Mac OS before Mac OS X. Everything *looks* OK in the GoLive
> editor and it also looked OK in the other editors I chose to check the code
> (other editors would have tipped me off, but I did not use one of those).
> However, it seems that the PSP engine, or whatever you want to call it, does
> not treat carriage returns as line endings, and therefore chokes badly when
> encountering code written this way.
> GoLive has a menu item where you can select the desired line terminator. I
> selected "Unix (LF)". This made no visible change to the document when
> viewed in GoLive, but then suddenly the <% ... %> PSP parts of the document
> worked perfectly.
> """
> I've confirmed that psp_parser.l expects lines of python code to be
> terminated with: "\r\n | \n | %>" so the fix should be a one liner.
> Index: src/psp_parser.l
> ===
> --- src/psp_parser.l (revision 398185)
> +++ src/psp_parser.l (working copy)
> @@ -119,7 +119,7 @@
> }
> }
>
> -\r\n|\n {
> +\r\n|\n|\r {
> psp_string_appendc(&PSP_PG(pycode), '\n');
>
> PSP_PG(seen_newline) = 1;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-167) If PythonDebug is On and error occurs, status is 200 when it should really be 500.
[ https://issues.apache.org/jira/browse/MODPYTHON-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-167. -- > If PythonDebug is On and error occurs, status is 200 when it should really be > 500. > -- > > Key: MODPYTHON-167 > URL: https://issues.apache.org/jira/browse/MODPYTHON-167 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.1.4, 3.2.8 > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > If PythonDebug is Off and an uncaught exception occurs in Python, the details > of that exception will be logged in the Apache error log file. At the same > time a 500 (HTTP_INTERNAL_SERVER_ERROR) response is returned to the client > with whatever the configured default 500 error response message is for Apache. > If PythonDebug is On, the details are still logged to the error log, but the > details of the exception will also be formatted and returned in the response > to the client. In returning this response though, the HTTP status code is > being returned as 200 (HTTP_OK) rather than the more correct 500 > (HTTP_INTERNAL_SERVER_ERROR). > By wrongly returning 200 rather than 500, one could theoretically run up > against problems like the response being cached, or if client was a non > interactive application, it may think it was an entirely valid response and > not flag in some way that it was actually an error. > The change to fix this in the code are as details in following patch. Note > that returning 500 will still result in the message being displayed in a web > browser, so for its intended purpose of displaying a traceback to a client, > it will still work as required. > Index: lib/python/mod_python/apache.py > === > --- lib/python/mod_python/apache.py (revision 396453) > +++ lib/python/mod_python/apache.py (working copy) > @@ -533,6 +533,7 @@ > return HTTP_INTERNAL_SERVER_ERROR > else: > # write to client > +req.status = HTTP_INTERNAL_SERVER_ERROR > req.content_type = 'text/html' > > s = '\n\nMod_python error: "%s %s"\n\n' % (phase, > hname) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-166) PythonHandlerModule doesn't set up PythonAuthenHandler registration.
[ https://issues.apache.org/jira/browse/MODPYTHON-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-166. -- > PythonHandlerModule doesn't set up PythonAuthenHandler registration. > > > Key: MODPYTHON-166 > URL: https://issues.apache.org/jira/browse/MODPYTHON-166 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.1.4, 3.2.8 > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > The PythonHandlerModule doesn't set up PythonAuthenHandler registration. > python_directive_handler(cmd, mconfig, "PythonPostReadRequestHandler", > val, SILENT); > python_directive_handler(cmd, mconfig, "PythonTransHandler", val, SILENT); > python_directive_handler(cmd, mconfig, "PythonHeaderParserHandler", val, > SILENT); > python_directive_handler(cmd, mconfig, "PythonAccessHandler", val, > SILENT); > # PythonAuthenHandler missing here. > python_directive_handler(cmd, mconfig, "PythonAuthzHandler", val, SILENT); > python_directive_handler(cmd, mconfig, "PythonTypeHandler", val, SILENT); > python_directive_handler(cmd, mconfig, "PythonHandler", val, SILENT); > python_directive_handler(cmd, mconfig, "PythonInitHandler", val, SILENT); > python_directive_handler(cmd, mconfig, "PythonLogHandler", val, SILENT); > python_directive_handler(cmd, mconfig, "PythonCleanupHandler", val, > SILENT); > This means that if one has Require directive in use in conjunction with > PythonHandlerModule, you get a 500 error and message in log of: > configuration error: couldn't check access. No groups file?: > /~grahamd/authz/index.py -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-165) Exporting functions from mod_python to allow access to interpreters etc.
[ https://issues.apache.org/jira/browse/MODPYTHON-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-165. -- > Exporting functions from mod_python to allow access to interpreters etc. > > > Key: MODPYTHON-165 > URL: https://issues.apache.org/jira/browse/MODPYTHON-165 > Project: mod_python > Issue Type: New Feature > Components: core > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > Attachments: mptest.tar.gz > > > 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-160) req.add_handler/req.handler and PythonInterpPerDirective
[
https://issues.apache.org/jira/browse/MODPYTHON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-160.
--
> req.add_handler/req.handler and PythonInterpPerDirective
>
>
> Key: MODPYTHON-160
> URL: https://issues.apache.org/jira/browse/MODPYTHON-160
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.8
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> MODPYTHON-125 made req.handler writable. Being able to now do this has
> uncovered a bug whereby if PythonInterpPerDirective is used mod_python can
> cause Apache to crash. Code to trigger the problem is:
> # .htaccess
> SetHandler mod_python
> PythonInterpPerDirective On
> PythonFixupHandler interpreter_1
> # interpreter_1.py
> from mod_python import apache
> def fixuphandler(req):
> req.log_error("fixuphandler")
> req.log_error("interpreter=%s"%req.interpreter)
> req.log_error("directory=%s"%req.hlist.directory)
> req.handler = "mod_python"
> req.add_handler("PythonHandler","interpreter_1")
> return apache.OK
> def handler(req):
> req.log_error("handler")
> req.log_error("interpreter=%s"%req.interpreter)
> req.log_error("directory=%s"%req.hlist.directory)
> req.content_type = 'text/plain'
> req.write('hello')
> return apache.OK
> In summary, if PythonHandler is not used in Apache configuration to enable
> mod_python but it is done by assignment to req.handler in fixup phase and
> then req.add_handler() is used to add a handler to be called for content
> phase, and PythonInterpPerDirective is being used, mod_python will cause
> Apache to crash.
> Location of crash not yet identified.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-159) multiline headers in multipart/form not handled
[ https://issues.apache.org/jira/browse/MODPYTHON-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-159. -- > multiline headers in multipart/form not handled > --- > > Key: MODPYTHON-159 > URL: https://issues.apache.org/jira/browse/MODPYTHON-159 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.1.4, 3.2.8 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > Attachments: MP159-20060911-grahamd-1.diff > > > Reported a long time back on mailing list that multiline headers in a > multipart/form post are not handled properly by util.FieldStorage class. > http://www.modpython.org/pipermail/mod_python/2001-November/012256.html > This seems to never have been addressed. Further comments confirming this > posted in: > http://www.mail-archive.com/python-dev@httpd.apache.org/msg01805.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-157) PythonInterpPerDirectory broken for directory request in fixup phase and earlier.
[
https://issues.apache.org/jira/browse/MODPYTHON-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-157.
--
> PythonInterpPerDirectory broken for directory request in fixup phase and
> earlier.
> -
>
> Key: MODPYTHON-157
> URL: https://issues.apache.org/jira/browse/MODPYTHON-157
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 2.7.10, 3.1.4, 3.2.8
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> The PythonInterpPerDirectory request creates distinct interpreters for each
> directory in the file system. The name of the directory is derived from
> req.filename.
> In determining the name of the interpreter from req.filename, it always
> assumes that if the request is against the directory and not a file in it,
> that req.filename will always have a trailing slash appended to it. This
> however is not the case, as trailing slash redirection is only performed by
> mod_dir at the end of the fixup handler phase. Thus the name of the
> interpreter will be wrong for handler run in fixup handler pahse or earlier
> and will actually be that of the parent directory.
> The code in select_interp_name() of src/mod_python.c which determines
> interpreter name is:
> /* base interpreter on directory where the file is found */
> if (req && ap_is_directory(req->pool, req->filename)) {
> /** XXX I suppose that if req->filename is a directory, there
> already
> is a trailing slash in req->filename. This is due to the
> fact
> that Apache redirect any request from /directory to
> /directory/.
> That's why the tests below are commented out, they should
> be useless.
> **/
> /* if (req->filename[strlen(req->filename)-1]=='/') { */
> return ap_make_dirstr_parent(req->pool, req->filename);
> /* }
> else {
> return ap_make_dirstr_parent(req->pool,
> apr_pstrcat(req->pool,
> req->filename,
> "/", NULL ));
> } */
> }
> Note that it actually has the code that would be required for this to work
> properly but it is commented out because of a wrong assumption that the
> trailing slash would always be there.
> Code simply has to be uncommented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MODPYTHON-217) Python 2.3 and simplified GIL state API still causes problems.
Python 2.3 and simplified GIL state API still causes problems.
--
Key: MODPYTHON-217
URL: https://issues.apache.org/jira/browse/MODPYTHON-217
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10, 3.3
Reporter: Graham Dumpleton
There are still problems in mod_python when third party extension modules are
used which make use of the Python simplified GIL state API. Specifically, if C
code makes calls to PyGILState_Ensure() when it already holds the Python GIL
and has an active thread state, but the active thread was one which was
originally created outside of Python, such as by Apache with mod_python, then
the call to PyGILState_Ensure() results in a dead lock. This is occurring
because the PyGILState_Ensure() function finds it does not know anything about
the current thread ID and therefore assumes it needs to create a new thread
state for it and make that the active thread state. In doing that though it
tries to acquire the GIL when the thread already holds it, resulting in the
deadlock.
At this stage it is believed this only occurs with Python 2.3 and shouldn't be
a problem with later versions of Python. This is the case as later versions of
Python were modified so that PyThreadState_New() will register the thread with
the underpinnings of the PyGILState_???() mechanism and because it already
knows about it, it will not attempt to create a new thread state object and so
the deadlock will not occur.
When C code is hand crafted it is unlikely that anyone would call
PyGILState_Ensure() when they already know they hold the GIL, ie., when calling
out of Python code, but SWIG when used with the -threads option does exactly
this. For example:
SWIGINTERN PyObject *_wrap_ap_get_server_version(PyObject
*SWIGUNUSEDPARM(self), PyObject *args) { PyObject *resultobj = 0;
char *result = 0 ;
SWIG_PYTHON_THREAD_BEGIN_BLOCK;
if (!PyArg_ParseTuple(args,(char *)":ap_get_server_version")) SWIG_fail;
{
SWIG_PYTHON_THREAD_BEGIN_ALLOW;
result = (char *)ap_get_server_version();
SWIG_PYTHON_THREAD_END_ALLOW;
}
resultobj = SWIG_FromCharPtr((const char *)result);
SWIG_PYTHON_THREAD_END_BLOCK;
return resultobj;
fail:
SWIG_PYTHON_THREAD_END_BLOCK;
return NULL;
}
where SWIG_PYTHON_THREAD_BEGIN_BLOCK eventually expands to a call to
PyGILState_Ensure().
The only solution to this problem would be for mod_python to behave differently
when it is acquiring a thread state against the main Python interpreter, ie.
'main_interpreter'. Specifically, rather than use PyThreadState_New() etc, it
should call PyGILState_Ensure() instead. When needing to release the main
Python interpreter it should call PyGILState_Release(). It should continue to
work as before for all other interpreters and anyone with GILState code would
need to ensure they are using 'main_interpreter'.
Unfortunately at the moment making this change is not completely straight
forward as when an interpreter is being released it isn't known that it is the
main Python interpreter. Thus some knowledge that it is the main interpreter
would need to be carried into the call. The only other option is that the list
of all active interpreters is traversed and the last one in the list is assumed
to be the main interpreter. Then if the interpreter being released matches that
then act differently.
Note that at present the acquire/release methods are exported as optional
functions so that other Apache modules use them. It is unlikely that anyone is
making use of them, so changing the in/out parameters of the functions would
possibly be acceptable.
Also note that maintaining support for threaded and non threaded Python and now
this GIL state variation is going to make the code even more messy. As such it
might be worthwhile considering dropping support for non threaded Python. These
days Python defaults to being threaded anyway, and highly unlikely that someone
would want to use non thread Python with mod_python anyway. When ever any
development of mod_python is done, no testing is ever done with a non threaded
Python anyway and so it is possibly questionable if that support still works.
FWIW, this issue came up as a result of queries expressed in:
http://www.modpython.org/pipermail/mod_python/2007-April/023445.html
The GIL state issue has attempted to be addressed before in MODPYTHON-77 but
this particular issue not captured in that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-155) req.add_handler() and inheritance of directory to be searched for module
[ https://issues.apache.org/jira/browse/MODPYTHON-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-155. -- > req.add_handler() and inheritance of directory to be searched for module > > > Key: MODPYTHON-155 > URL: https://issues.apache.org/jira/browse/MODPYTHON-155 > Project: mod_python > Issue Type: Sub-task > Components: importer > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > The documentation for req.add_handler() says: > """Optional dir is a string containing the name of the directory to be added > to the pythonpath. If no directory is specified, then, if there is already a > handler of the same type specified, its directory is inherited, otherwise the > directory of the presently executing handler is used. I there is a PythonPath > directive in effect, then sys.path will be set exactly according to it (no > directories added, the dir argument is ignored).""" > This comment about the directory being inherited from the prior or currently > executing handler is actually bogus as the code does not do anything specific > at all to try and implement such behaviour. If it works this way at all it is > partly by luck as what will actually dictate where the module specified to > the req.add_handler() method is found is the current order of directories > specified in sys.path. Since additional directories added into sys.path by > the old importer can be performed in effectively random order, behaviour > could actually be quite random if the same module name were used in multiple > directories. > Because the new importer doesn't add directories into sys.path for > Python*Handler directives, a problem will currently arise if no directory is > supplied to req.add_handler(). Specifically, a module may not be able to be > found. This is because it can no longer fall back on to fact that with old > module importer, the directory corresponding to the Python*Handler directive > would be listed in sys.path somewhere. > Thus, the documented behaviour for req.add_handler() when the directory > hasn't been set needs to actually be implemented as described with an > appropriate directory being calculated at the time that req.add_handler() is > called with that directory being recorded as needing to be searched for the > module. In changing the code though, if old and new importers are going to be > supported during a transition phase, it must detect when the new module > importer is being used and only do this when it is, as otherwise it will > screw up how modules are found for the old importer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-154) PythonPath overriding use of Python*Handler directory.
[ https://issues.apache.org/jira/browse/MODPYTHON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-154. -- > PythonPath overriding use of Python*Handler directory. > -- > > Key: MODPYTHON-154 > URL: https://issues.apache.org/jira/browse/MODPYTHON-154 > Project: mod_python > Issue Type: Sub-task > Components: importer > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > The behaviour of the old importer is such that if the PythonPath directive > has been used in the same or parent configuration context, then any physical > directory corresponding to where the Python*Handler directive was used, is > not added to sys.path. > The new importer currently preserves the above behaviour, but since the new > importer does not actually add the directory associated with the > Python*Handler directive into sys.path, it doesn't seem to make any sense > that setting PythonPath should cause the directory the Python*Handler > directive is associated with to be ignored. > Thus propose that PythonPath should be kept quite distinct from directories > in document tree for which Python*Handler is specified for and setting > PythonPath will would no longer cause directory Python*Handler directive is > specified for to be ignored. > Overall, this should actually eliminate unexpected behaviour whereby user > sets PythonPath and then finds their modules in document tree can't be found. > The only solution to this with the old importer is to add the directories in > the document tree explicitly to PythonPath directive. > If there is some valid reason that the new importer should never look in the > document tree for modules, then it would be better handled by some sort of > PythonOption rather than it be a side effect of having used the PythonPath > directive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-156) Module imports from server side includes and new importer.
[
https://issues.apache.org/jira/browse/MODPYTHON-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-156.
--
> Module imports from server side includes and new importer.
> --
>
> Key: MODPYTHON-156
> URL: https://issues.apache.org/jira/browse/MODPYTHON-156
> Project: mod_python
> Issue Type: Sub-task
> Components: importer
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> With old module importer, where Python*Handler directives are used in a
> directory context, that directory is added to sys.path. Now where Python code
> is being used with server side includes in that same directory and code of
> form:
> module = apache.import_module("xxx")
> is used with "xxx.py" also being in the same directory, it will be found due
> to the directory being added to sys.path.
> With the new module importer, the directory isn't added to sys.path and so
> the module would not be found.
> In the case of a handler module (rather than SSI Python code), such a module
> import would still work, as the new module importer is smart enough to
> realise that the caller was also imported using the new module importer and
> thus would look in the same directory first or as necessary, in the directory
> the Python*Handler directive was specified for. This will not work for SSI
> code though, as it is not part of an imported module and is eval/exec'd on
> each page request.
> What is thus required is for the global environment in which the SSI code is
> executed for a specific page, to be automatically marked up in such a way
> that the new module importer believes it was imported as a module by the new
> module importer, thus triggering it to look in the same directory for modules.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-153) Add req.discard_request_body().
[ https://issues.apache.org/jira/browse/MODPYTHON-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-153. -- > Add req.discard_request_body(). > --- > > Key: MODPYTHON-153 > URL: https://issues.apache.org/jira/browse/MODPYTHON-153 > Project: mod_python > Issue Type: New Feature > Components: core > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > In HTTP/1.1 any method may include a request body, whereas in HTTP/1.0 only > POST and PUT were allowed to. To avoid any potential problems if a handler > were trying to emulate in part the default Apache handler for requests, in > would be appropriate for a handler to ensure that any request body is > discarded. Apache provides a function specifically for this purpose which is > called ap_discard_request_body(). For completeness this function should be > available in the request object API as req.discard_request_body(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-152) req.main/prev from subrequest should yield true Python request object.
[ https://issues.apache.org/jira/browse/MODPYTHON-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-152. -- > req.main/prev from subrequest should yield true Python request object. > -- > > Key: MODPYTHON-152 > URL: https://issues.apache.org/jira/browse/MODPYTHON-152 > Project: mod_python > Issue Type: Improvement > Components: core > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > When a sub request is triggered using req.internal_redirect(), it is possible > to access the details of the request_rec for the parent request by acessing > req.main. Access will be via an instance of the Python request object > wrapper, but rather than it referring to the actual Python request object > wrapper instance that may have already been created for the parent request, a > new instance is created. This means that a sub request cannot access > attributes that may have been explicitly added to the Python request object > wrapper in the main request. > For example, in a parent request Python handler it may have gone: > req.session = Session.Session(req) > ... > req.internal_redirect(...) > In the sub request, it is not currently possible to do something like: > req.session = req.prev.session > where it is a reasonable expectation that trying to access parent request > would allow added attributes to be seen. > What would need to be done is for actions associated with accessing req.main, > req.prev and req.next to use the get_request_object() function to get hold of > request object so that if one already exists, it will be used and if not one > will be created. > Whether this could be done though would depend on what happens when a sub > request is actually processed within the context of a distinct Python > interpreter. Would there be issues with the Python request object wrapper > being used from two distinct Python interpreters, especially where a > multithreaded MPM were being used. > If this isn't a problem, the next issue is how get_request_object() requires > that the interpreter name and phase be supplied with the supplied values > overriding those already in the request object. > For interpreter name this would be a problem as accessing the main request > object from a sub request in a different interpreter would change the value > of interpreter seen by the parent request when it gets control back. > The solution to this should perhaps be that the interpreter name should not > even be stored in the request object wrapper to begin with. Instead, when > req.interpreter is accessed, internally to mod_python it should map this to > retrieving the value of apache.interpreter. This would eliminate the need for > the interpreter name to even be supplied to get_request_object(), simplifying > its calling interface. > As to the phase attribute, all that is probably required is that when access > req.main, req.next or req.prev it passes in phase as a NULL pointer. By doing > this it wouldn't override any existing value if the request object already > existed. If the request object didn't exist, then req.phase would return > None. This latter situation would only exist where the internal redirect was > performed by something other than 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-150) make_obcallback not thread protected
[ https://issues.apache.org/jira/browse/MODPYTHON-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-150. -- > make_obcallback not thread protected > > > Key: MODPYTHON-150 > URL: https://issues.apache.org/jira/browse/MODPYTHON-150 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.1.4, 3.2.8 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > In get_interpreter() function of src/mod_python.c the check of whether or not > the callback object has been created is not within the bounds of the > acquisition of the interpreters lock. As a result, in a multithreaded MPM, > although the creation of the interpreter itself is protected so that only one > thread will get to create it, multiple threads may decide the need to call > make_obcallback(). > In the past this hasn't mattered, but now that apache.init() is doing more > complicated things, such as caching parameters as global variables and also > doing fiddles with the callback object to allow optional use of new module > importer, problems can start to arise. > To fix the issue the release of the interpreters lock needs to be moved to > the end of the get_interpreter() function. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-151) PythonDebug exception error page doesn't escape special HTML characters.
[ https://issues.apache.org/jira/browse/MODPYTHON-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-151. -- > PythonDebug exception error page doesn't escape special HTML characters. > > > Key: MODPYTHON-151 > URL: https://issues.apache.org/jira/browse/MODPYTHON-151 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 2.7.10, 3.1.4, 3.2.8 > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > When an exception occurs in a handler and PythonDebug is On, an error page is > generated and returned to the client. The traceback and details of the > exception will be output within a section, however the content > put in the section is included as is and no escaping is performed on special > HTML characters. This means that if the details of the exception include any > special HTML characters, it can stuff up the formatting of the page and/or > information could on face value be lost. > For example the new importer will generate a specific exception where the > response from a handler is not of the correct type. > AssertionError: Handler has returned result or raised SERVER_RETURN > exception with argument having non integer type. Type of value returned > was , whereas expected . > Because this includes <> characters, it actuall displays in the resultant > HTML page as: > AssertionError: Handler has returned result or raised SERVER_RETURN > exception with argument having non integer type. Type of value returned > was , whereas expected . > The error reporter therefore should pass content through cgi.escape(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-149) Allow cross subdomain sessions.
[
https://issues.apache.org/jira/browse/MODPYTHON-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-149.
--
> Allow cross subdomain sessions.
> ---
>
> Key: MODPYTHON-149
> URL: https://issues.apache.org/jira/browse/MODPYTHON-149
> Project: mod_python
> Issue Type: Improvement
> Components: session
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-148) Additional constants for mod_python.apache module.
[
https://issues.apache.org/jira/browse/MODPYTHON-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-148.
--
> Additional constants for mod_python.apache module.
> --
>
> Key: MODPYTHON-148
> URL: https://issues.apache.org/jira/browse/MODPYTHON-148
> Project: mod_python
> Issue Type: New Feature
> Components: core
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
>Priority: Minor
> Fix For: 3.3
>
>
> Apache defines the following:
> /** Magic for mod_cgi[d] */
> #define CGI_MAGIC_TYPE "application/x-httpd-cgi"
> /** Magic for mod_include */
> #define INCLUDES_MAGIC_TYPE "text/x-server-parsed-html"
> /** Magic for mod_include */
> #define INCLUDES_MAGIC_TYPE3 "text/x-server-parsed-html3"
> /** Magic for mod_dir */
> #define DIR_MAGIC_TYPE "httpd/unix-directory"
> There should be equivalents available as constants in "mod_python.apache"
> module.
> Apache defines the following:
> #define PROXYREQ_NONE 0 /**< No proxy */
> #define PROXYREQ_PROXY 1/**< Standard proxy */
> #define PROXYREQ_REVERSE 2 /**< Reverse proxy */
> #define PROXYREQ_RESPONSE 3 /**< Origin response */
> The PROXYREQ_RESPONSE value is missing from "mod_python.apache".
> Apache defines the following:
> #define HTTP_UPGRADE_REQUIRED 426
> This isn't present in mod_python.apache.
> Apache defines the following:
> /** Send 413 error if message has any body */
> #define REQUEST_NO_BODY 0
> /** Send 411 error if body without Content-Length */
> #define REQUEST_CHUNKED_ERROR1
> /** If chunked, remove the chunks for me. */
> #define REQUEST_CHUNKED_DECHUNK 2
> /** @} // values_request_rec_body */
> These are necessary to understand what req.read_body means. In practice,
> don't think they are relevant to mod_python handlers, but for completeness
> should be added.
> Apache defines the following:
> /**
> * @brief Enumeration of connection keepalive options
> */
> typedef enum {
> AP_CONN_UNKNOWN,
> AP_CONN_CLOSE,
> AP_CONN_KEEPALIVE
> } ap_conn_keepalive_e;
> These are needed to understand req.connection.keepalive. Because they a enum
> values, need to be populated in mod_python._apache module when module is
> initialised and reference made in mod_python.apache module.
> The only other thing from httpd.h which seems of interest is the DOCTYPE
> macro strings. Don't do anything about them for the time being.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-145) Make number of mutex locks configurable at apache startup
[ https://issues.apache.org/jira/browse/MODPYTHON-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-145. -- > Make number of mutex locks configurable at apache startup > - > > Key: MODPYTHON-145 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-147) PythonImport directives causing duplicate entries in sys.path.
[ https://issues.apache.org/jira/browse/MODPYTHON-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-147. -- > PythonImport directives causing duplicate entries in sys.path. > -- > > Key: MODPYTHON-147 > URL: https://issues.apache.org/jira/browse/MODPYTHON-147 > Project: mod_python > Issue Type: Bug >Affects Versions: 3.1.4, 3.2.8 > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > When PythonPath is used at global scope within the Apache configuration and > more than one PythonImport directive is used against the same interpreter, > duplicated entries can be added to sys.path. > This is because src/mod_python.c is evaluating PythonPath every time that a > PythonImport directive is acted upon even if a PythonImport directive for the > same interpreter has already been processed. > In other words, if you have: > PythonPath "['/some/path']+sys.path" > PythonImport module1 testing > PythonImport module2 testing > PythonImport module3 testing > then '/some/path' will be added to sys.path within context of interpreter > called 'testing' a total of three times. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-144) Make apache._server/apace._interpreter part of public API.
[ https://issues.apache.org/jira/browse/MODPYTHON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-144. -- > Make apache._server/apace._interpreter part of public API. > -- > > Key: MODPYTHON-144 > URL: https://issues.apache.org/jira/browse/MODPYTHON-144 > Project: mod_python > Issue Type: Improvement > Components: core > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > Within the mod_python.apache module there exists two private variables called > "_server" and "_interpreter". These are initialised when an interpreter is > first created. The variables are set to be an instance of the mod_python > "serverobject" and the name of the interpreter. In effect, these would be the > same as are available to a request handler as "req.server" and > "req.interpreter". > The problem with those in the "req" object is that they are only available to > the request handler. If these variables in the "mod_python.apache" module are > made part of the public API, they would then be accessible by any code. Since > "server.get_options()" now exists and "server.get_config()" works properly, > making these public would allow code running at global scope when a module is > being imported to consult the server level config and/or options to customise > their runtime behavour. > Thus, proposed that these variables be renamed to "apache.server" and > "apache.interpreter". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-143) Implement and integrate a new module importer.
[ https://issues.apache.org/jira/browse/MODPYTHON-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-143. -- > Implement and integrate a new module importer. > -- > > Key: MODPYTHON-143 > URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-142) Make req.no_cache and req.no_local_copy writable.
[ https://issues.apache.org/jira/browse/MODPYTHON-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-142. -- > Make req.no_cache and req.no_local_copy writable. > - > > Key: MODPYTHON-142 > URL: https://issues.apache.org/jira/browse/MODPYTHON-142 > Project: mod_python > Issue Type: Improvement > Components: core >Affects Versions: 3.2.8 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > Attachments: MP142_20060305_grahamd_1.diff > > > If a handler sets req.no_cache to be true, then Apache will internally add > appropriate "Expires" header. Also the req.no_cache attribute is consulted > by mod_cache to know when not to cache. The alternative is that a handler > must know to set both: > req.headers_out['Cache-Control'] = 'no-cache' > req.headers_out['Expires'] = '-1' > It would be better to allow handlers to set req.no_cache as it isolates them > from any future changes in respect of special headers that may need to be > additionally set if standards change in any way. > Not entirely sure if req.no_local_copy attribute is somehow related. It > somehow affects whether 304 errors are returned in some cases. Certain > modules such as mod_include set this, so no reason that a mod_python handler > wouldn't want to set it also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-141) Allow handlers to trigger proxying of requests.
[ https://issues.apache.org/jira/browse/MODPYTHON-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-141. -- > Allow handlers to trigger proxying of requests. > --- > > Key: MODPYTHON-141 > URL: https://issues.apache.org/jira/browse/MODPYTHON-141 > Project: mod_python > Issue Type: Improvement > Components: core >Affects 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. - You can reply to this email to add a comment to the issue online.
