Re: Vote on whether to integrate server side include (SSI) support.
* Graham Dumpleton [EMAIL PROTECTED] wrote: Do you have examples of SSI tag handlers that you might implement this way if such a feature were available? I ask as it all good to speculate on such a feature, but like this generic #python tag, would it in itself be used either? Actually, I'd hardly use the the #python tag by itself, but specific functions, provided by my application as needed (like the SSI templates are provided by my application but designed by someone else!). All you thus get by having an explicit registered tag is that that Python is used can be hidden and a user would be none the wiser. Exactly that's the point. Separation of concerns - I'm not a friend of a raw programming language in a template. Therefore - if you really want to pass httpd features to mod_python, it would be nice to consider this one :) nd
Cross-platform query: _FILE_OFFSET_BITS in python and httpd
Could folks with access to different OS's try the following: Compare output of apxs -q CPPFLAGS with the value of _FILE_OFFSET_BITS in pyconfig.h. For example, on my Fedora Core 4 i386 system (stock httpd and python): $ /usr/sbin/apxs -q CPPFLAGS -DSSL_EXPERIMENTAL_ENGINE [note - no mention of _FILE_OFFSET_BITS above] $ grep _FILE_OFFSET_BITS /usr/include/python2.4/pyconfig.h #define _FILE_OFFSET_BITS 64 In case you're wondering, this is in relation to https://issues.apache.org/jira/browse/MODPYTHON-138 and to some degree https://issues.apache.org/jira/browse/MODPYTHON-20 and probably a few other unexplained issues. What the output on Fedora Core 4 means is that essentially Python and APR/httpd are compiled in an incomatible way - in APR the size of an inode (ino_t) is 32 bits and in Python it is 64 bits (this is what _FILE_OFFSET_BITS 64 does). This issue goes unnoticed when Python.h is included after http.h, but becomes very obvious if you put Python.h before http.h - httpd will segfault on the first request because the request_rec (which includes finfo, which includes ino_t inode) becomes incompatible between httpd and mod_python and anything past finfo in request_rec structure is junk (off by 4 bytes). I wanted to see how widespread this problem is. I think the right solution is for configure to catch this (exactly how to best detect this I'm not yet sure) and stop cold. Thanks, Grisha
Re: Cross-platform query: _FILE_OFFSET_BITS in python and httpd
Debian Sid (httpd and python2.3 are stock debian): $ /usr/bin/apxs2 -q CPPFLAGS $ grep _FILE_OFFSET_BITS /usr/include/python2.3/pyconfig.h #define _FILE_OFFSET_BITS 64 Jim Gregory (Grisha) Trubetskoy wrote: Could folks with access to different OS's try the following: Compare output of apxs -q CPPFLAGS with the value of _FILE_OFFSET_BITS in pyconfig.h. For example, on my Fedora Core 4 i386 system (stock httpd and python): $ /usr/sbin/apxs -q CPPFLAGS -DSSL_EXPERIMENTAL_ENGINE [note - no mention of _FILE_OFFSET_BITS above] $ grep _FILE_OFFSET_BITS /usr/include/python2.4/pyconfig.h #define _FILE_OFFSET_BITS 64 In case you're wondering, this is in relation to https://issues.apache.org/jira/browse/MODPYTHON-138 and to some degree https://issues.apache.org/jira/browse/MODPYTHON-20 and probably a few other unexplained issues. What the output on Fedora Core 4 means is that essentially Python and APR/httpd are compiled in an incomatible way - in APR the size of an inode (ino_t) is 32 bits and in Python it is 64 bits (this is what _FILE_OFFSET_BITS 64 does). This issue goes unnoticed when Python.h is included after http.h, but becomes very obvious if you put Python.h before http.h - httpd will segfault on the first request because the request_rec (which includes finfo, which includes ino_t inode) becomes incompatible between httpd and mod_python and anything past finfo in request_rec structure is junk (off by 4 bytes). I wanted to see how widespread this problem is. I think the right solution is for configure to catch this (exactly how to best detect this I'm not yet sure) and stop cold. Thanks, Grisha
Re: Cross-platform query: _FILE_OFFSET_BITS in python and httpd
On 15/03/2006, at 8:45 AM, Gregory (Grisha) Trubetskoy wrote: Could folks with access to different OS's try the following: Compare output of apxs -q CPPFLAGS with the value of _FILE_OFFSET_BITS in pyconfig.h. For example, on my Fedora Core 4 i386 system (stock httpd and python): $ /usr/sbin/apxs -q CPPFLAGS -DSSL_EXPERIMENTAL_ENGINE [note - no mention of _FILE_OFFSET_BITS above] $ grep _FILE_OFFSET_BITS /usr/include/python2.4/pyconfig.h #define _FILE_OFFSET_BITS 64 Apache 2.0.55/Python 2.3/Mac OS X 10.3.9 ~ [507]$ /usr/local/apache-2.0/bin/apxs -q CPPFLAGS ~ [508]$ grep _FILE_OFFSET_BITS /System/Library/Frameworks/Python.framework/Versions/Current/include/ python2.3/pyconfig.h /* #undef _FILE_OFFSET_BITS */
Re: Cross-platform query: _FILE_OFFSET_BITS in python and httpd
On 3/14/06, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED] wrote: What the output on Fedora Core 4 means is that essentially Python and APR/httpd are compiled in an incomatible way - in APR the size of an inode (ino_t) is 32 bits and in Python it is 64 bits (this is what _FILE_OFFSET_BITS 64 does). APR 1.0+ has LFS turned on by default. This means that httpd 2.0.xx will have 32-bit files by default, but that LFS should be activated for 2.1 and beyond. The mod_perl guys have some tricks to get around this conflict as they run into this same mismatch as well. -- justin
Bug in Apache ap_internal_fast_redirect() function????
I know this is the wrong list to be asking this, but thought I
would ask before I go and get my self subscribed to some Apache
server list just to ask the question as I know some more involved
in Apache core lurk here. :-)
I have been looking at a way of solving:
https://issues.apache.org/jira/browse/MODPYTHON-146
The basic problem described in this issue is that when DirectoryIndex
directive is used, data added to the Python request object by a fixup
handler for the actual file doesn't get propogated back into the main
request object pertaining to the request against the directory. This
is because mod_dir uses ap_internal_fast_redirect() to do some of the
nasty work and Python stuff isn't part of the request_rec so does not
get copied from subrequest request_rec to main request_rec.
In investigating this, am starting to question whether what the function
ap_internal_fast_redirect() is doing is even sensible in some parts
anyway. Specifically, it does:
r-headers_out = apr_table_overlay(r-pool, rr-headers_out,
r-headers_out);
r-err_headers_out = apr_table_overlay(r-pool, rr-err_headers_out,
r-err_headers_out);
r-subprocess_env = apr_table_overlay(r-pool, rr-subprocess_env,
r-subprocess_env);
In this code r is the main request_rec and rr is that for the sub
request which matched actual file in DirectoryIndex directive file list.
The problem here is that apr_table_overlay() merges the contents of two
Apache tables. What this means is that if the same key exists in both
tables, that from rr doesn't replace that in r, instead the result
contains both key/value pairs even if they have the same value for that
key.
Now I tend to work out my home directory, thus mod_userdir comes into
play. One of the things it does is add an entry to req.notes recording
what my username is. This is just one example, there are others entries
added as well by other stuff. For example, if I access
/~grahamd/index.html
the req.notes table contains:
{'no-etag': '', 'ap-mime-exceptions-list': 'Ϣ', 'mod_userdir_user':
'grahamd', 'python_init_ran': '1'}
I could therefore access the username using:
req.notes[mod_userdir_user]
this would yield a string containing grahamd.
If now I access the directory itself as /~grahamd/ and rely on
DirectoryIndex
directive to map it to index.html file, I get:
{'no-etag': '', 'mod_userdir_user': 'grahamd', 'python_init_ran': '1',
'ap-mime-exceptions-list': 'œ\', 'mod_userdir_user': 'grahamd'}
Note how there are two entries for mod_userdir_user. When I try and
get
the username now, I will actually get an array:
['grahamd', 'grahamd']
If my handler had assumed that that was always going to be a string, it
would promptly generate some sort of exception when used in a way that
wasn't going to work for an array.
The question I guess is whether ap_internal_fast_redirect() is wrong for
merging the tables, or whether any handler (including those not written
in mod_python) are supposed to handle this strangeness?
I have only talked about req.notes here, but same issue applies to the
req.headers_out, req.err_headers_out and req.subprocess_env table
objects,
as the same issue can come up with them as well.
Graham
[jira] Commented: (MODPYTHON-104) Allow Python code callouts with mod_include (SSI).
[
http://issues.apache.org/jira/browse/MODPYTHON-104?page=comments#action_12370468
]
Graham Dumpleton commented on MODPYTHON-104:
Patches for SSI support will not work with Apache 2.2. Names of macros have
changed which mean it will not compile and the prototype of a registered
handler for include tags has changed meaning that it will then crash when
called, even after macros fixed, as arguments don't match up. :-(
Allow Python code callouts with mod_include (SSI).
--
Key: MODPYTHON-104
URL: http://issues.apache.org/jira/browse/MODPYTHON-104
Project: mod_python
Type: New Feature
Components: core
Reporter: Graham Dumpleton
Assignee: Graham Dumpleton
Fix For: 3.3
Attachments: grahamd_20060126_1_mod_include.diff,
grahamd_20060226_MP104_1.diff
The mod_include module supporting server side includes (SSI), provides a
means of registering new element tags which trigger callouts to other code in
separate Apache modules. This is used for example in mod_perl to allow Perl
language code to be used with server side includes:
!--#perl sub=MySSI::remote_host --
!--#perl arg=Hello arg=SSI arg=World
sub=sub {
my($r, @args) = @_;
print qq(@args);
}
--
An equivalent feature for Python was previously asked about on the mailing
list back in 2004:
http://www.modpython.org/pipermail/mod_python/2004-January/014832.html
Since it seems entirely reasonable that such integration of mod_python and
mod_include would be possible, thought it would be good to log it as a
possible new feature.
Because of SSI's support for basic conditionals, includes and other callout
mechanisms, would be a good quick and dirty way of doing templating without
having to resort to PSP, or other high level templating systems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: mod_python roadmap
...
Any other issues for a 3.2.9 release?
(This is where Mike L. should advocate for MODPYTHON-93 - Improved
FieldStorage. ;) )
Eh, yeah, I have a suggestion:
MODPYTHON-93 - Improved FieldStorage
- Stop putting simple key/value pairs into StringIO objects, put them simple
str objects
- Use a dictionary for fields
- Allow any file-like object ('write' method) to be used in a make_file callback
(all the coding is already done)
Mike Looijmans
Philips Natlab / Topic Automation
