mod_wsgi configuration question
wmiller
files without explicitly declaring the application object within each
script file? If not, is there a elegant/crude work-around?
Along the same lines, if that were possible, it would be nice to also
assume defaults for the return variables of the start_response
function so it (start_response) wouldn't have to be declared
explicitly. Then, any changes to the defaults or to the environ
settings could optionally be set/declared and retrieved in the script
file:
<%
# default status = '200 OK'
start_response('403 Forbidden', [('Content-Type', 'text/html')])
var = "Access Denied"
%>
<html>
<body>
{var}
</body>
</html>
The above example also assumes there would be no need to explicitly
return content because the processed script file itself would serve as
the return content. Admittedly, the goal is a bit unconventional
having the template file serve also as the wsgi application script
file with several assumptions built-in. The motivation if it's not
already obvious is to return to a one file per URL application
environment along the lines of PHP (performance and security issues
permitting).
-Walter
gert
example http://code.google.com/p/appwsgi/source/browse/trunk/httpd.conf
About templates, it is not going to work like php without a framework.
But I do recommend to think for a minute and wonder do I really need
templates when there is so much stuff you can request with
javascript ? Writing python code without html in it, has so many
benefits.
There are many many big frameworks out there in many flavors that all
work with mod_wsgi and there is also http://code.google.com/appengine/
with some major restrictions but word mentioning.
Other example if you have ff3 or chrome browser, ie7 has some
javascript issues.
This does not use any frame works or templates at all, it basically
just static files with some specific tasks loaded in by java script
carried out by mod_wsgi in pure basic python code. You might look at
it as a multi threading web page :)
http://91.121.53.159/appwsgi/www/barcode/barcode.htm
http://91.121.53.159/appwsgi/www/register/register.htm (fill in
anything you want, creates new user, also push on the picture if you
have flash installed)
Anyway just examples.
source code http://code.google.com/p/appwsgi/source/browse/trunk
(sign) No more templates :-) Vote javascript (sign)
gert
WSGIScriptAliasMatch ^/wsgi-scripts/([^/]+) /web/wsgi-scripts/$1.wsgi
What would be a more Graham approved solution, for security
reasons :-)
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIScriptAliasMatch
Clodoaldo Pinto Neto
http://groups.google.com/group/modwsgi/browse_thread/thread/fbda3f584046585f#
>
> -Walter
> >
>
wmiller
>
yes, i recall the post and it was encouraging to see at least some
potential in a one file per URL setup. In fact I started the thread
asking about the feasibility of this design approach. Now that I've
had time to think about how to configure this, I realized it would be
nice if the usual requirements for a single WSGI application script
file to display it's own templated content:
- the explicit need for an application entry point.
- the explicit need for a start_response function call.
- the explicit need to return content.
could be handled by additional configuration directives or rewrite
rules or some other work-around and have reasonable default settings
built-in, e.g. start_response status and header values.
In the meantime, I'll look into emulating this design using
WSGIScriptAliasMatch to map several template files to one WSGI
application script file.
-Walter
Graham Dumpleton
I have been asked something similar a number of times. I don't know
why but it is always to me direct and not on the mailing list. Not
sure if it means the others were embarrassed about their yearnings for
something more like PHP or not. ;-)
Anyway, what you are wanting is not WSGI. That said, it doesn't mean
that you cannot write a WSGI application which acts as an intermediary
or proxy to interpret the files contents however you want. In effect
you are just creating a variant of a Python templating system. Rather
than you independently having to implement all the URL dispatch
yourself though, one can use aspects of Apache configuration to allow
Apache to do it for you. The result isn't strictly a pure WSGI
application as it will only work under Apache/mod_wsgi, but if you
don't care, then that is not an issue.
Quoting some bits from prior mails I have sent about this ....
The Apache configuration you want is:
Action pyhp-scripts /pyhp-interpreter
WSGIScriptAlias /pyhp-interpreter /some/path/pyhp.wsgi
AddHandler pyhp-scripts .pyhp
You would then put your .pyhp files where ever you want in directories
covered by the AddHandler. When ever a request comes in for a file
with .pyhp extension, Apache will actually invoke WSGI application at
/pyhp-interpreter to handle the request.
The WSGI environ for the WSGI application would be something like:
DOCUMENT_ROOT: '/Library/WebServer/Documents'
GATEWAY_INTERFACE: 'CGI/1.1'
HTTP_ACCEPT: 'text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5'
HTTP_ACCEPT_ENCODING: 'gzip, deflate'
HTTP_ACCEPT_LANGUAGE: 'en-us'
HTTP_CONNECTION: 'keep-alive'
HTTP_HOST: 'localhost'
HTTP_USER_AGENT: 'Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5;
en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2
Safari/525.20.1'
PATH: '/usr/bin:/bin:/usr/sbin:/sbin'
PATH_INFO: '/~grahamd/foo.pyhp'
PATH_TRANSLATED: '/Users/grahamd/Sites/foo.pyhp'
QUERY_STRING: ''
REDIRECT_HANDLER: 'pyhp-scripts'
REDIRECT_SCRIPT_URI: 'http://localhost/~grahamd/foo.pyhp'
REDIRECT_SCRIPT_URL: '/~grahamd/foo.pyhp'
REDIRECT_STATUS: '200'
REDIRECT_URL: '/~grahamd/foo.pyhp'
REMOTE_ADDR: '::1'
REMOTE_PORT: '50491'
REQUEST_METHOD: 'GET'
REQUEST_URI: '/~grahamd/foo.pyhp'
SCRIPT_FILENAME: '/Users/grahamd/Sites/echo.wsgi'
SCRIPT_NAME: '/pyhp-interpreter'
SCRIPT_URI: 'http://localhost/~grahamd/foo.pyhp'
SCRIPT_URL: '/~grahamd/foo.pyhp'
SERVER_ADDR: '::1'
SERVER_ADMIN: 'y...@example.com'
SERVER_NAME: 'localhost'
SERVER_PORT: '80'
SERVER_PROTOCOL: 'HTTP/1.1'
SERVER_SIGNATURE: ''
SERVER_SOFTWARE: 'Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.7l
DAV/2 mod_wsgi/3.0-TRUNK Python/2.5.1'
mod_wsgi.application_group: 'graham-dumpletons-imac-2.local|/pyhp-interpreter'
mod_wsgi.callable_object: 'application'
mod_wsgi.listener_host: ''
mod_wsgi.listener_port: '80'
mod_wsgi.process_group: '~grahamd'
mod_wsgi.script_reloading: '1'
mod_wsgi.version: (3, 0)
wsgi.errors: <mod_wsgi.Log object at 0x1007888d0>
wsgi.file_wrapper: <built-in method file_wrapper of mod_wsgi.Adapter
object at 0x100726a80>
wsgi.input: <mod_wsgi.Input object at 0x10077fcb0>
wsgi.multiprocess: False
wsgi.multithread: True
wsgi.run_once: False
wsgi.url_scheme: 'http'
wsgi.version: (1, 0)
The actual file which was the matched target of the request would be
in 'PATH_TRANSLATED'. The WSGI application would then read and process
that file however it wants. This might include it parsing file,
converting it into executable Python code, performing caching and only
rereading files from disk when target file changes etc etc. What you
do is really up to you at this point, but at least Apache has done the
URL dispatching to file based resources for you so you do not have to
worry about that.
Graham
gert
cashing ch*t in python, just you can have your own templates ?
wmiller
wrote:
> why but it is always to me direct and not on the mailing list. Not
> sure if it means the others were embarrassed about their yearnings for
> something more like PHP or not. ;-)
>
> Anyway, what you are wanting is not WSGI. That said, it doesn't mean
established by WSGI and be able to plug-in some of the middleware in
the same way as a traditional WSGI application.
> that you cannot write a WSGI application which acts as an intermediary
> or proxy to interpret the files contents however you want. In effect
> you are just creating a variant of a Python templating system. Rather
> than you independently having to implement all the URL dispatch
> yourself though, one can use aspects of Apache configuration to allow
> Apache to do it for you. The result isn't strictly a pure WSGI
> application as it will only work under Apache/mod_wsgi, but if you
> don't care, then that is not an issue.
preferred as Apache/mod_wsgi is the primary target currently but also
because the hope would be that it could be set up similarly without
too much effort in other environments (nginx, IIS). Ideally this
would also allow the developer to simultaneously to do WSGI style URL
dispatch if they need to.
and see if it works as envisioned. Hopefully the result will be a PHP-
style templating system that provides most of the benefits of a WSGI
application.
-Walter
wmiller
> So let me get this straight, you are going to rewrite all this parsing
> cashing ch*t in python, just you can have your own templates ?
option to choose pure WSGI application development or a PHP-style
application where each file can stand individually as the main point
of entry for the application or a mixture of both. It's sometimes
nice to have stand-alone tangible files acting both as a template and
application entry point similar to Karrigell's PIH script files.
And the good news is with so many great code examples available, and
the WSGI standards already in place, it should be relatively easy to
implement.
-Walter
gert
approach not idea)
I mean you go from mod_wsgi and make it act as a cripple mod_scgi with
GIL stuff and no stdout to transform it into mod_php using a
interpreter that execute instructions as fast as a elephant doing
backstrokes in a swimming pool compared to c ?
wmiller
equal to that of a pure WSGI application. If not, I'd love to hear of
another approach that offers the same features/benefits/options.
gert
gert
prefetching process management. And you change the tiny little wsgi
part of it. Note that, Graham actually has a translator around his
neck because of all the c code he has been writen in his life his
voice can only speaks in floating point numbers. So don't worry if you
don't understand it at first neither of us does :)
But never the less that is the way you should do it. I mean mod_php is
also nothing but c, and there is a good reason for that not to split
up in different mod's or scripts.
Graham Dumpleton
It doesn't need C code and can be just as fast as normal WSGI
application. Am too busy at the moment to explain further, maybe later
today.
Graham
gert
When Graham mind is in binary mode you can see on a egg scan his
brainwaves resembling IEEE 802.11 :-)
gert
something like import apache and import cgi but then import wsgi and
import php
where php module defines your template specification like php.echo for
example.
Its just a bit weird that the wsgi guy's put there heads together to
redesign the cgi environment resulting into a wsgi standard where they
consider print as something very very bad. And now we use there design
to reinvent print again and name it echo :-)
Anyway i think Guido would have nightmares if "<% %>" emerged in his
syntax. Actually in the end i think i would be easier to modify
mod_php to work with python code.
Maybe Graham can squeeze something in the mod_php source code, it
suddenly starts running python code the php way as wel :-)
gert
Graham Dumpleton
Presumably abandoned when they realised that it wasn't perhaps a
useful thing after all.
Last updated: October 21, 2003
Graham
Nimrod A. Abing
Either that, or the Spanish Inquisition got to him after that last update ;-)
--
Best Regards,
Nimrod A. Abing
W http://arsenic.ph/
W http://preownedcar.com/
W http://preownedbike.com/
W http://abing.gotdns.com/
gert
Anyway wsgi is not that bad, it just different and makes your code
look better. Ok the auto reload script thing is not as flexible as php
yet but Graham is working on a PythonPathMatch and a
WSGIDaemonReloading that would make your daemons restart itself on
script changes and find other modules in your host directory. He just
doesn't know it yet :-)
wmiller
> application. Am too busy at the moment to explain further, maybe later
> today.
>
> Graham
Action pyp-scripts /pyp-interpreter
WSGIScriptAlias /pyp-interpreter /home/username/www/dev/wsgi/
pyp.wsgi
<Directory /home/username/www/dev/htdocs>
AddHandler pyp-scripts .pyp
</Directory>
The templating is working as designed and it's pretty responsive
subjectively speaking. For those who might be interested, I'll post
some code and benchmarks after taking some time to clean up the code
and figure out a "safe" way to use eval within the template.
Thanks again for the tips!
-Walter
gert
how do i import a pyp file into a pyp file ?
what happens if i make changes to the imported pyp file ?
can it eval normal wsgi apps ?
Graham Dumpleton
> lol :)
>
> Anyway wsgi is not that bad, it just different and makes your code
> look better. Ok the auto reload script thing is not as flexible as php
> yet but Graham is working on a PythonPathMatch and a
> WSGIDaemonReloading that would make your daemons restart itself on
> script changes and find other modules in your host directory.
http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode
and what options already exists for automatically reloading and how
you can trigger this in your own application.
Graham
Graham Dumpleton
You should avoid 'eval', at least in any context where the input could
come from a remote user by way of URL, post data, query string etc
etc. What are you trying to do that requires eval?
Graham
wmiller
> > subjectively speaking. For those who might be interested, I'll post
> > some code and benchmarks after taking some time to clean up the code
> > and figure out a "safe" way to use eval within the template.
>
> You should avoid 'eval', at least in any context where the input could
> come from a remote user by way of URL, post data, query string etc
> etc. What are you trying to do that requires eval?
>
> Graham
<%
def fib(n):
a, b = 0, 1
while b < n:
print(str(b) + ", ")
a, b = b, a+b
return b-a
var = fib(100)
%>
<br><br>
{var}
looks like this in a browser:
"""
1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89,
55
"""
here the the print statement is modified to just return output to the
browser. Also, variables surrounded by "{" "}" are returned to the
browser based on the variables in locals(). I'm still holding out
hope that there'll be a way to make eval safe or maybe figure out a
better alternative to allow scripting in the template.
-Walter
Dan Fairs
> browser. Also, variables surrounded by "{" "}" are returned to the
> browser based on the variables in locals(). I'm still holding out
> hope that there'll be a way to make eval safe or maybe figure out a
> better alternative to allow scripting in the template.
You're probably looking for something like RestrictedPython:
http://pypi.python.org/pypi/RestrictedPython/
I'd personally avoid this, though and - er - just write a WSGI
application!
Cheers,
Dan
--
Dan Fairs <dan....@gmail.com> | http://www.fezconsulting.com/
wmiller
yes, thanks, I was looking for something like this as a good
replacement for rexec.
-Walter
gert
> <%
> def fib(n):
> a, b = 0, 1
> while b < n:
> print(str(b) + ", ")
> a, b = b, a+b
> return b-a
>
> var = fib(100)
> %>
> <br><br>
> {var}
def fib(n):
a, b = 0, 1
while b < n:
print(str(b) + ", ")
a, b = b, a+b
return b-a
var = fib(100)
"""%
<br><br>
{var}
Would make it python compatible, wsgi compatible, unit test
compatible, import compatible, eval compatible, cgi compaitible, and
many other compatible python things :)
wmiller
>
> def fib(n):
> a, b = 0, 1
> while b < n:
> print(str(b) + ", ")
> a, b = b, a+b
> return b-a
>
> var = fib(100)
>
> """%
> <br><br>
> {var}
> %"""
>
> Would make it python compatible, wsgi compatible, unit test
> compatible, import compatible, eval compatible, cgi compaitible, and
> many other compatible python things :)
highlighting compatible ; ) Would be nice if editors had a multiple
language highlighting mode for the same document based on opening/
closing tags/tokens. I'm using Komodo Edit and it seems like it only
allows one language style per document.
-Walter
Graham Dumpleton
You should perhaps look at how Python Server Pages (PSP) in mod_python
is implemented. Documentation at:
http://www.modpython.org/live/current/doc-html/pyapi-psp.html
But look at mod_python source code.
Your comments about 'print' show up one of the problems with a lot of
these attempts to add Python into HTML. That is the expectation that
'print' output should appear in response stream.
There are two approaches which people normally use for this. The first
is to replace sys.stdout with some object which routes output back
into response stream. The problem with replacing sys.stdout is
ensuring it is safe in multithreaded environment. You can't just
replace sys.stdout for life time of your request as in multithreaded
context another request handler could do same thing and output could
go to wrong response. You also have problems where third party module
has used 'print' to produce debug output. Instead of going to a log
file, that debug output will end up in response when not intended.
The second approach is to compile template code and then replace
'print' opcode with alternate opcodes which direct output to a
specific stream object corresponding to response. This is the better
approach but requires more work and better done in conjunction with a
page code caching scheme to avoid having to do it every time.
A scheme which just tries to do textual substitution of 'print' in
code before evaling/compiling it is not a good idea.
Which of the above are you trying to use to ensure 'print' goes where you want?
As to eval, ultimately somewhere the code has to be compiled and run
and so you can't avoid evaluating it. The problem is just ensuring
that text which comes from URL, headers or post content doesn't get
expanded into code string before being evaluated.
Where exactly are you using 'eval'?
Graham
wmiller
> is implemented. Documentation at:
>
> http://www.modpython.org/live/current/doc-html/pyapi-psp.html
>
> But look at mod_python source code.
for a a few minor details like having to explicitly declare separate
tags for expressions, directives, and comments. Also, the hope with
this implemented using modwsgi is that traditional wsgi apps can
coexist along side these PHP/ASP-style wsgi templates with the later
having the option to utilize wsgi middleware. I'll take a look at the
source and see what can be learned, especially how it executes the
Python code in the template.
> Your comments about 'print' show up one of the problems with a lot of
> these attempts to add Python into HTML. That is the expectation that
> 'print' output should appear in response stream.
>
> There are two approaches which people normally use for this. The first
> is to replace sys.stdout with some object which routes output back
> into response stream. The problem with replacing sys.stdout is
> ensuring it is safe in multithreaded environment. You can't just
> replace sys.stdout for life time of your request as in multithreaded
> context another request handler could do same thing and output could
> go to wrong response. You also have problems where third party module
> has used 'print' to produce debug output. Instead of going to a log
> file, that debug output will end up in response when not intended.
>
> The second approach is to compile template code and then replace
> 'print' opcode with alternate opcodes which direct output to a
> specific stream object corresponding to response. This is the better
> approach but requires more work and better done in conjunction with a
> page code caching scheme to avoid having to do it every time.
>
> A scheme which just tries to do textual substitution of 'print' in
> code before evaling/compiling it is not a good idea.
'print' with 'printwrite', then compile, then pass to eval with
'printwrite' passed to a function to append to output. Would be nice
to replace 'print' opcode after compiling but not sure how that's done
- will have to look into that. What's the issue with substituting
'print' with another keyword before compiling? Instead of
'printwrite', another long unlikely-to-be-used keyword could be
substituted if the concern is that 'printwrite' could be used in the
code somewhere for other purposes.
> Which of the above are you trying to use to ensure 'print' goes where you want?
>
> As to eval, ultimately somewhere the code has to be compiled and run
> and so you can't avoid evaluating it. The problem is just ensuring
> that text which comes from URL, headers or post content doesn't get
> expanded into code string before being evaluated.
from the server-side source, I'm not clear on how text from URL,
headers or post content could manifest itself in the source code
before compilation.
> Where exactly are you using 'eval'?
is compiled, then passed to eval with optional argument of
{'printwrite': function-to-append-to-output} to add to the globals().
-Walter
Graham Dumpleton
>> A scheme which just tries to do textual substitution of 'print' in
>> code before evaling/compiling it is not a good idea.
>
> this is the approach. For code between <% %> tags, first replace
> 'print' with 'printwrite', then compile, then pass to eval with
> 'printwrite' passed to a function to append to output. Would be nice
> to replace 'print' opcode after compiling but not sure how that's done
> - will have to look into that. What's the issue with substituting
> 'print' with another keyword before compiling? Instead of
> 'printwrite', another long unlikely-to-be-used keyword could be
> substituted if the concern is that 'printwrite' could be used in the
> code somewhere for other purposes.
The problem with textual substitution, where you aren't properly
parsing code is that you might replace 'print' in a context where it
is not as a key word. For example, in text strings. Your substitution
thus has to be partly intelligent.
>> Which of the above are you trying to use to ensure 'print' goes where you want?
>>
>> As to eval, ultimately somewhere the code has to be compiled and run
>> and so you can't avoid evaluating it. The problem is just ensuring
>> that text which comes from URL, headers or post content doesn't get
>> expanded into code string before being evaluated.
>
> this where a good example would help. The way the code is compiled
> from the server-side source, I'm not clear on how text from URL,
> headers or post content could manifest itself in the source code
> before compilation.
It may well not be an issue, in which case finding an alternative to
'eval' may not be necessary. Still do check out what mod_python PSP
does. Even if you don't use its C based lexer stuff, you might learn
from how it in the end executes the code it creates.
Graham