2009/8/31 Evgeny <[email protected]>: > > within php you can use > > virtual("/some/url"); > > this seems to work without specially configured output filters in > apache,
That will work because PHP is doing a sub request. Would only work thought where using mod_php to have PHP run inside of Apache and not when using PHP under fastcgi etc. > I've also tried to add > > AddOutputFilter INCLUDES .php > > and within php have <!--#include virtual="/test.wsgi"--> and that for > some reason did not work. I believe PHP is usually implemented as a filter rather than a handler. Thus, this may not work due to order in which filters are triggered. Ie., if INCLUDES executed before PHP rather than after. Graham > On Aug 30, 5:25 pm, Evgeny <[email protected]> wrote: >> It works. Here is what I did for my minimal test. >> >> httpd.conf: >> <VirtualHost ...> >> .... >> DocumentRoot /path/to/dir >> AddHandler wsgi-script .wsgi >> AddType text/html .shtml >> AddOutputFilter INCLUDES .shtml >> ... >> </VirtualHost> >> >> <Directory /path/to/dir> >> Options ExecCGI Includes >> ... more stuff needed to run php application >> </Directory> >> >> test.shtml: >> <body> >> <!--#include virtual="/test.wsgi"--> >> </body> >> >> test.wsgi: >> def application(environ, start_response): >> status = '200 OK' >> response_headers = [('Content-type','text/plain')] >> start_response(status, response_headers) >> return ['Hello!'] >> >> On Aug 30, 4:49 pm, Graham Dumpleton <[email protected]> >> wrote: >> >> > 2009/8/31 Evgeny <[email protected]>: >> >> > > Graham, >> > > sorry. That's exactly what I meant. >> > > I have a php application into which I want to inject bits generated by >> > > django, >> > > where django app runs under wsgi. >> >> > > Want those bits to be included via >> > > <!--#include virtual="/some/url" --> >> > > within the same VirtualHost. >> >> > > I'd write django to give output in form of html snippets rather than >> > > fully fledged pages. >> >> > > Will this work? >> >> > > (I've seen some conflicting posts on the subject, so decided to ask >> > > here) >> >> > Where are the conflicting posts about it. I can't see what the issue >> > is, so long as things are configured correctly in Apache to allow it. >> >> > What have you tried so far? >> >> > Graham >> >> > > Thanks. >> >> > > On Aug 29, 8:52 pm, Graham Dumpleton <[email protected]> >> > > wrote: >> > >> 2009/8/30 Evgeny <[email protected]>: >> >> > >> > I'm also curious about this - will Apache server side includes (SSI) >> > >> > work with the scheme offered below? >> >> > >> If you mean by way of: >> >> > >> <!--#include virtual="/some/url" --> >> >> > >> The SSI include is done by way of Apache sub request and so full URL >> > >> passing is still applied. Thus, is same as having triggered request >> > >> from outside of server. >> >> > >> If this doesn't answer question, not sure what you are asking and you >> > >> will need to explain further. >> >> > >> Graham >> >> > >> > Thanks! >> >> > >> > Evgeny. >> >> > >> > On Aug 10, 4:18 pm, Graham Dumpleton <[email protected]> >> > >> > wrote: >> > >> >> 2009/8/11 Haes <[email protected]>: >> >> > >> >> > Hi, >> >> > >> >> > I'm looking to integrate wsgi applications (Django in this case) >> > >> >> > into >> > >> >> > a legacy PHP web application. The legacy app is way to big to be >> > >> >> > completely rewritten all at once. >> >> > >> >> > Right now there are two wsgi apps installed in two subdirectories >> > >> >> > and >> > >> >> > more to come. The only way to configure apache was to set up a >> > >> >> > WSGIDaemonProcess for each of the two wsgi apps and point the >> > >> >> > WSGIScriptAlias to the respective subdirectory. That way I'll need >> > >> >> > at >> > >> >> > least two daemon processes (http and https) for every part I will >> > >> >> > exchange. >> >> > >> >> You don't need seperate daemon processes for HTTP and HTTPS, you can >> > >> >> share the same one. You can achieve this in two ways. >> >> > >> >> The first is to make the daemon process globally available by placing >> > >> >> WSGIDaemonProcess directive outside of the VirtualHost container and >> > >> >> then use WSGIProcessGroup to reference the same daemon process group. >> >> > >> >> Using this first approach means that daemon process is usable from >> > >> >> any >> > >> >> VirtualHost, even ones not for the virtual host you need it for, if >> > >> >> hosting many virtual hosts. >> >> > >> >> The second and which constrains the use of the daemon process group >> > >> >> to >> > >> >> virtual hosts with same ServerName, is to place WSGIDaemonProcess >> > >> >> directive in one (not all), of the virtual hosts for that ServerName. >> > >> >> That is, put in in VirtualHost for port 80. Then use WSGIProcessGroup >> > >> >> in VirtualHost for port 80 and 443 and refer to it. >> >> > >> >> This works because you can use WSGIProcessGroup to reference a daemon >> > >> >> process defined for same ServerName regardless of what port the >> > >> >> VirtualHost is for. Thus can reference across matching VirtualHost >> > >> >> containers. >> >> > >> >> I actually would have preferred that this only work that way for >> > >> >> 80/443, but not possible with the way that Apache works for me to >> > >> >> filter based on anything except ServerName value. >> >> > >> >> > Is there a way to only set up one set of WSGIDaemonProcess'es and >> > >> >> > just >> > >> >> > exclude certain path's from this configuration and let them being >> > >> >> > served by mod_php? >> >> > >> >> As gert said, first step is to use AddHandler to map .wsgi files to >> > >> >> mod_wsgi. You need to go further than that though as you don't want >> > >> >> lots of .wsgi files for each URL. You also don't want to have to add >> > >> >> lots of Alias directives for each PHP script. Instead you want to >> > >> >> route any URLs which don't map to static files or to PHP through to a >> > >> >> single WSGI application. To do that, would use: >> >> > >> >> Options ExecCGI >> >> > >> >> AddHandler wsgi-script .wsgi >> >> > >> >> RewriteEngine On >> > >> >> RewriteCond %{REQUEST_FILENAME} !-f >> > >> >> RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L] >> >> > >> >> That is, add a site.wsgi which contains the code to map to your >> > >> >> Django >> > >> >> application, with Django code being stored outside of HTTP document >> > >> >> tree somewhere. Whenever Apache can't find a physical resource file, >> > >> >> ie., static file or PHP script, it will send it to Django. >> >> > >> >> The only trick with this is that because of the rewrite, the >> > >> >> SCRIPT_NAME for Django willinclude'site.wsgi', which you don't want >> > >> >> because if you use Django to generate full URLs it willincludeit. >> > >> >> Thus you want to use a WSGI middleware wrapper to drop that from >> > >> >> SCRIPT_NAME. >> >> > >> >> import os, sys >> > >> >> sys.path.append('/usr/local/django') >> > >> >> os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings' >> >> > >> >> import django.core.handlers.wsgi >> >> > >> >> _application = django.core.handlers.wsgi.WSGIHandler() >> >> > >> >> import posixpath >> >> > >> >> def application(environ, start_response): >> > >> >> # Wrapper to set SCRIPT_NAME to actual mount point. >> > >> >> environ['SCRIPT_NAME'] = >> > >> >> posixpath.dirname(environ['SCRIPT_NAME']) >> > >> >> if environ['SCRIPT_NAME'] == '/': >> > >> >> environ['SCRIPT_NAME'] = '' >> > >> >> return _application(environ, start_response) >> >> > >> >> Now, whether the root of the web site will be routed to Django >> > >> >> probably depends on whether you have a resource corresponding to >> > >> >> DirectoryIndex. Can't remember exactly how that works. >> >> > >> >> Anyway, this is all documented in: >> >> > >> >> http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apa... >> >> > >> >> Have a read of that section, and the remainder of the document, have >> > >> >> a >> > >> >> play and come back with any questions or clarifications. >> >> > >> >> Graham > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
