You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Graham Dumpleton <gr...@dscpl.com.au> on 2006/03/10 04:50:44 UTC
Vote on whether to integrate server side include (SSI) support.
I have had patches for adding server side include support into
mod_python ready for a while now. See:
https://issues.apache.org/jira/browse/MODPYTHON-104
In short, it would add the ability to add Python code into files
being served up through the INCLUDES output filter. More
commonly this is known as server side include (SSI). For example:
<!--#python exec="
from mod_python import apache
import cgi
import sys
parts = apache.import_module('parts')
def _escape(object):
return cgi.escape(str(object))
"-->
<html>
<body>
<pre>
<!--#python eval="_escape(str(globals().keys()))"-->
<!--#python eval="_escape(str(locals().keys()))"-->
<!--#python exec="
print >> filter
for key in filter.req.subprocess_env:
print >> filter, _escape((key, filter.req.subprocess_env[key]))
"-->
<!--#python eval="parts.content()"-->
</pre>
</body>
</html>
One could say that there is an overlap between this and the
mod_python.psp handler, but the SSI feature is a builtin feature of
Apache and it make sense to support it. Using SSI, if one was mad
enough, you could even have Python and Perl code appearing in the one
file.
Anyway, the point of this email is to get a decision on whether this
major new feature should or should not be added into mod_python.
Core developer votes obviously matter the most, but others are more
than welcome to voice an opinion.
So, is it a Yes or a No?
Graham
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Deron Meranda <de...@gmail.com>.
+1 (although I'm indifferent about into which release it goes)
--
Deron Meranda
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Jorey Bump <li...@joreybump.com>.
+1
Graham Dumpleton wrote:
> I have had patches for adding server side include support into
> mod_python ready for a while now. See:
>
> https://issues.apache.org/jira/browse/MODPYTHON-104
>
> In short, it would add the ability to add Python code into files
> being served up through the INCLUDES output filter. More
> commonly this is known as server side include (SSI). For example:
>
> <!--#python exec="
> from mod_python import apache
> import cgi
> import sys
> parts = apache.import_module('parts')
> def _escape(object):
> return cgi.escape(str(object))
> "-->
> <html>
> <body>
> <pre>
> <!--#python eval="_escape(str(globals().keys()))"-->
> <!--#python eval="_escape(str(locals().keys()))"-->
> <!--#python exec="
> print >> filter
> for key in filter.req.subprocess_env:
> print >> filter, _escape((key, filter.req.subprocess_env[key]))
> "-->
> <!--#python eval="parts.content()"-->
> </pre>
> </body>
> </html>
>
> One could say that there is an overlap between this and the
> mod_python.psp handler, but the SSI feature is a builtin feature of
> Apache and it make sense to support it. Using SSI, if one was mad
> enough, you could even have Python and Perl code appearing in the one
> file.
>
> Anyway, the point of this email is to get a decision on whether this
> major new feature should or should not be added into mod_python.
>
> Core developer votes obviously matter the most, but others are more
> than welcome to voice an opinion.
>
> So, is it a Yes or a No?
>
> Graham
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Nick <ni...@dd.revealed.net>.
+0
Graham Dumpleton wrote:
> Anyway, the point of this email is to get a decision on whether this
> major new feature should or should not be added into mod_python.
>
> Core developer votes obviously matter the most, but others are more
> than welcome to voice an opinion.
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
On 14/03/2006, at 7:33 PM, André Malo wrote:
> * Graham Dumpleton <gr...@dscpl.com.au> 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 :)
I would agree that excessive raw programming language code in a template
is not good either. I however don't see minimal callouts, which
effectively what a custom tag is doing anyway, as that bad.
What I am about to describe can only be done using a backdoor with the
current SSI support. This is the case because of bug described in:
https://issues.apache.org/jira/browse/MODPYTHON-146
which means it will not work where DirectoryIndex is matching files.
When that is fixed, a notionally private variable reference just needs
to be made part of the public API and this will all work. You could use
the notionally private variable name now if you wanted to play, it just
will not work on DirectoryIndex matched files. In other words, have
simply hidden fact this can be done until that other issue is fixed.
First off, in my .htaccess file I have:
PythonFixupHandler _dispatch
I have not turned on INCLUDES output filter in the configuration as I
do it dynamically, but you could do it in the configuration instead.
My fixup handler then contains:
from mod_python import apache
def header():
return "<p>HEADER</p>"
def footer():
return "<p>FOOTER</p>"
def other(filter):
print >> filter, "<p>OTHER</p>"
def fixuphandler(req):
if req.content_type == "text/html":
# Enable INCLUDES output filter for request.
req.add_output_filter("INCLUDES")
# Setup globals visible to INCLUDES files.
req.ssi_globals = {}
req.ssi_globals["header"] = header
req.ssi_globals["footer"] = footer
req.ssi_globals["other"] = other
return apache.OK
In my HTML file being processed by INCLUDES output filter, I can then
use:
<html>
<body>
<!--#python eval="header()" -->
<p>TEXT</p>
<!--#python eval="other(filter)" -->
<p>TEXT</p>
<!--#python eval="footer()" -->
</pre>
</body>
</html>
What I am doing is using the fixup handler to enabled the INCLUDES
output filter based on type of file matched by request, but am also
creating a dictionary object preloaded with data accessible to the
code executing within context of file being processed by INCLUDES
output filter. This dictionary actual becomes the globals of the code.
That is, equivalent to saying:
eval "header()" in req.ssi_globals
Thus one can avoid having a whole lot of excessive code in the HTML
to perform imports, setup data etc. This can all be done in the
fixup handler for all files in the directory to be processed by the
INCLUDES output filter. The result is that the HTML is quite simple
and not really that much more complicated than having custom tags.
In respect of customised tag handlers, this is more flexible, as a
customised tag handler resides in the global Apache server namespace.
That is, it is accessible to everything. With the above mechanism, what
is available and callable can be specific to a particular part of the
URL namespace, specifically, whatever context the fixup handler is
specified for. With a bit of extra work, you could even allow fixup
handlers specific to each resource and allow file level customisations
as well as directory level.
That customised tag handlers are in the global namespace presents
other issues as well. The first is that they have to be registered at
the time that mod_python is being initialised. To do this, custom
directives would need to be created and they must be used only in
main sever configuration context. That is, outside of all VirtualHost,
Location, Directory or Files directive containers. As mentioned before,
means they cant apply to a specific context and a user who only has
access to a .htaccess file cant define them.
The next issue would be coming up with a simple API on the Python side
for processing the callback when a registered tag were called. Doing
this in C code is quite fiddly and not sure how one could present a nice
API to do the same if you wanted to have the same abilities for
processing tag arguments and values etc.
What might be a better approach is to harness some other changes I have
in mind for mod_python down the track. That is, I want to export some
functions from mod_python which would be callable from other Apache
modules using the optional function API. These functions would provide
ability to get a named Python interpreter, get a Python wrapped request
object, filter object or server object and the ability to finally
release
the interpreter lock.
With these, if one was really serious about having a customised tag
handler which behind the scenes was implemented using Python, one could
start by writing a custom C Apache module which registers the tag, and
when called processes arguments and sets up filter bucket chain etc,
in C code and then grabs Python interpreter and then executes a call
into actual Python code stored in an installed Python module.
I am sure you will say that this is too much work, but it becomes a
balance between having full access to Apache internals to properly
register the tag handler and process arguments, versus tolerating that
it is still Python code in the template, albeit this would allow things
to be done quicker and not require a full blown separate Apache module
to be created.
The only other option is to invest a lot of time in coming up with an
additional Python API which wraps lower level bits of Apache. This is
what mod_perl effectively does, but am not sure the effort is worth it.
You might also be able to come up with a slightly more high level API
related to just tag handlers which isn't a direct map to lower level
concepts and is more Pythonic, but it is still effort. As is, the SSI
support I did add was simple to implement and thus partly why I did it.
If was going to be too much more complicated, I wouldn't have bothered.
Graham
Re: Vote on whether to integrate server side include (SSI) support.
Posted by André Malo <nd...@perlig.de>.
* Graham Dumpleton <gr...@dscpl.com.au> 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
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
On 12/03/2006, at 9:04 PM, Graham Dumpleton wrote:
>
> On 12/03/2006, at 8:25 PM, André Malo wrote:
>
>> * Graham Dumpleton wrote:
>>
>>> Not seeing any negatives, I am going to go ahead and commit the SSI
>>> stuff. Comments that this is just another way to skin a cat are true,
>>> even if a small cat. I guess the reason for doing it is to fill out
>>> those basic features that can be filled out by using just what Apache
>>> provides.
>>
>> If that's a point, you know, what would be really great in this case?
>> To be
>> able to register own SSI handlers using mod_python instead of (or in
>> addition to) this generic #python thingy, which nobody really seems
>> to be
>> able to classify/justify. Like registering a name and a callback
>> function
>> with a fixed signature.
>>
>> What do you think?
>
> I did think about it but deferred the idea in preference to at least
> getting some basic support for use of Python code with SSI in place.
> In other words, to take this initial step and then see whether people
> even consider using server side includes a viable way of doing stuff.
> These days there is so much focus on full blown frameworks that I am
> not sure that SSI even gets used much. I could well be wrong on that
> point.
>
> 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?
BTW, I should point out that one of the reasons for not rushing straight
into allowing tag handler registration is that the same can be achieved
with what is provided, albeit just more verbose and still exposing the
fact that Python is used. All you need to do is put your common code
that
the tag handler would do in a Python function, import that module and
call it. That is, you don't have to enumerate the complete code within
the actual file being processed by mod_includes. The function can either
query filter.req.subprocess_env for input parameters, or the point in
the file where it is called can extract out the required values and pass
them as explicit arguments to the function being called.
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.
Graham
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
On 12/03/2006, at 8:25 PM, André Malo wrote:
> * Graham Dumpleton wrote:
>
>> Not seeing any negatives, I am going to go ahead and commit the SSI
>> stuff. Comments that this is just another way to skin a cat are true,
>> even if a small cat. I guess the reason for doing it is to fill out
>> those basic features that can be filled out by using just what Apache
>> provides.
>
> If that's a point, you know, what would be really great in this case?
> To be
> able to register own SSI handlers using mod_python instead of (or in
> addition to) this generic #python thingy, which nobody really seems to
> be
> able to classify/justify. Like registering a name and a callback
> function
> with a fixed signature.
>
> What do you think?
I did think about it but deferred the idea in preference to at least
getting some basic support for use of Python code with SSI in place.
In other words, to take this initial step and then see whether people
even consider using server side includes a viable way of doing stuff.
These days there is so much focus on full blown frameworks that I am
not sure that SSI even gets used much. I could well be wrong on that
point.
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?
Graham
Re: Vote on whether to integrate server side include (SSI) support.
Posted by André Malo <nd...@perlig.de>.
* Graham Dumpleton wrote:
> Not seeing any negatives, I am going to go ahead and commit the SSI
> stuff. Comments that this is just another way to skin a cat are true,
> even if a small cat. I guess the reason for doing it is to fill out
> those basic features that can be filled out by using just what Apache
> provides.
If that's a point, you know, what would be really great in this case? To be
able to register own SSI handlers using mod_python instead of (or in
addition to) this generic #python thingy, which nobody really seems to be
able to classify/justify. Like registering a name and a callback function
with a fixed signature.
What do you think?
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# André Malo, <http://www.perlig.de/> #
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> I don't understand this enough to have an opinion on it, seems like
> another way to skin a cat,
Yes, but perhaps just for small cats. ;)
Quoting from http://httpd.apache.org/docs/1.3/howto/ssi.html
"SSI is certainly not a replacement for CGI, or other technologies used
for generating dynamic web pages. But it is a great way to add small
amounts of dynamic content to pages, without doing a lot of extra work."
Jim
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
Not seeing any negatives, I am going to go ahead and commit the SSI
stuff. Comments that this is just another way to skin a cat are true,
even if a small cat. I guess the reason for doing it is to fill out
those basic features that can be filled out by using just what Apache
provides.
Anyway, I'll try and get around to writing one of my mini articles
about the feature and also use some of that for inclusion into the
mod_python documentation itself. Maybe from writing a mini article
it might become more apparent how its simplicity can be just as useful
as any other approach for getting small tasks down quickly.
Graham
On 11/03/2006, at 1:43 AM, Gregory (Grisha) Trubetskoy wrote:
>
> I don't understand this enough to have an opinion on it, seems like
> another way to skin a cat, but to really form an opinion would require
> some thinking on my part at least (may be I'm getting thick with age).
>
> I think it'd be great if those who send in +1's (or -1's) would
> explain why they think this is good, and even if it's not so useful,
> then is it worth being supported and maintained in the future.
>
> Grisha
>
> On Fri, 10 Mar 2006, Jim Gallacher wrote:
>
>> +1
>>
>> Graham Dumpleton wrote:
>>> I have had patches for adding server side include support into
>>> mod_python ready for a while now. See:
>>> https://issues.apache.org/jira/browse/MODPYTHON-104
>>> In short, it would add the ability to add Python code into files
>>> being served up through the INCLUDES output filter. More
>>> commonly this is known as server side include (SSI). For example:
>>> <!--#python exec=" from mod_python import apache import cgi import
>>> sys parts = apache.import_module('parts') def _escape(object):
>>> return cgi.escape(str(object)) "--> <html> <body> <pre>
>>> <!--#python eval="_escape(str(globals().keys()))"--> <!--#python
>>> eval="_escape(str(locals().keys()))"--> <!--#python exec=" print >>
>>> filter for key in filter.req.subprocess_env: print >> filter,
>>> _escape((key, filter.req.subprocess_env[key])) "--> <!--#python
>>> eval="parts.content()"--> </pre> </body> </html> One could say
>>> that there is an overlap between this and the
>>> mod_python.psp handler, but the SSI feature is a builtin feature of
>>> Apache and it make sense to support it. Using SSI, if one was mad
>>> enough, you could even have Python and Perl code appearing in the one
>>> file.
>>> Anyway, the point of this email is to get a decision on whether this
>>> major new feature should or should not be added into mod_python.
>>> Core developer votes obviously matter the most, but others are more
>>> than welcome to voice an opinion.
>>> So, is it a Yes or a No?
>>> Graham
>>
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Jorey Bump <li...@joreybump.com>.
Gregory (Grisha) Trubetskoy wrote:
> I don't understand this enough to have an opinion on it, seems like
> another way to skin a cat, but to really form an opinion would require
> some thinking on my part at least (may be I'm getting thick with age).
>> Graham Dumpleton wrote:
>>> Using SSI, if one was mad
>>> enough, you could even have Python and Perl code appearing in the one
>>> file.
I'm intrigued by this statement. I've always found SSI to be limited,
but this could turn that notion on its head. Imagine writing an
application that uses HTML, JavaScript, CSS, Python, Perl, PHP, Ruby,
Lisp, & SQL, all in one file. Now, that's job security! :)
But seriously, I feel that exploring these hooks could lead to
discoveries that might benefit mod_python in the long run, as long as it
doesn't introduce stability or security issues.
Re: Vote on whether to integrate server side include (SSI) support.
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
I don't understand this enough to have an opinion on it, seems like
another way to skin a cat, but to really form an opinion would require
some thinking on my part at least (may be I'm getting thick with age).
I think it'd be great if those who send in +1's (or -1's) would explain
why they think this is good, and even if it's not so useful, then is it
worth being supported and maintained in the future.
Grisha
On Fri, 10 Mar 2006, Jim Gallacher wrote:
> +1
>
> Graham Dumpleton wrote:
>> I have had patches for adding server side include support into
>> mod_python ready for a while now. See:
>>
>> https://issues.apache.org/jira/browse/MODPYTHON-104
>>
>> In short, it would add the ability to add Python code into files
>> being served up through the INCLUDES output filter. More
>> commonly this is known as server side include (SSI). For example:
>>
>> <!--#python exec=" from mod_python import apache import cgi import sys
>> parts = apache.import_module('parts') def _escape(object): return
>> cgi.escape(str(object)) "--> <html> <body> <pre> <!--#python
>> eval="_escape(str(globals().keys()))"--> <!--#python
>> eval="_escape(str(locals().keys()))"--> <!--#python exec=" print >> filter
>> for key in filter.req.subprocess_env: print >> filter, _escape((key,
>> filter.req.subprocess_env[key])) "--> <!--#python
>> eval="parts.content()"--> </pre> </body> </html>
>> One could say that there is an overlap between this and the
>> mod_python.psp handler, but the SSI feature is a builtin feature of
>> Apache and it make sense to support it. Using SSI, if one was mad
>> enough, you could even have Python and Perl code appearing in the one
>> file.
>>
>> Anyway, the point of this email is to get a decision on whether this
>> major new feature should or should not be added into mod_python.
>>
>> Core developer votes obviously matter the most, but others are more
>> than welcome to voice an opinion.
>>
>> So, is it a Yes or a No?
>>
>> Graham
>>
>
Re: Vote on whether to integrate server side include (SSI) support.
Posted by Jim Gallacher <jp...@jgassociates.ca>.
+1
Graham Dumpleton wrote:
> I have had patches for adding server side include support into
> mod_python ready for a while now. See:
>
> https://issues.apache.org/jira/browse/MODPYTHON-104
>
> In short, it would add the ability to add Python code into files
> being served up through the INCLUDES output filter. More
> commonly this is known as server side include (SSI). For example:
>
> <!--#python exec="
> from mod_python import apache
> import cgi
> import sys
> parts = apache.import_module('parts')
> def _escape(object):
> return cgi.escape(str(object))
> "-->
> <html>
> <body>
> <pre>
> <!--#python eval="_escape(str(globals().keys()))"-->
> <!--#python eval="_escape(str(locals().keys()))"-->
> <!--#python exec="
> print >> filter
> for key in filter.req.subprocess_env:
> print >> filter, _escape((key, filter.req.subprocess_env[key]))
> "-->
> <!--#python eval="parts.content()"-->
> </pre>
> </body>
> </html>
>
> One could say that there is an overlap between this and the
> mod_python.psp handler, but the SSI feature is a builtin feature of
> Apache and it make sense to support it. Using SSI, if one was mad
> enough, you could even have Python and Perl code appearing in the one
> file.
>
> Anyway, the point of this email is to get a decision on whether this
> major new feature should or should not be added into mod_python.
>
> Core developer votes obviously matter the most, but others are more
> than welcome to voice an opinion.
>
> So, is it a Yes or a No?
>
> Graham
>